Crocos Engineering Blog

株式会社クロコスのエンジニアブログです。 Facebook アプリに関することをメインに、情報発信をしていきます！

[crocos]

Crocos Wiki を Crowi として公開しました

こんにちは @sotarok です。

はじめにお知らせ

既にお知らせしてあったとおり、株式会社クロコスは今月いっぱいでヤフー株式会社に吸収合併されます。

てことで、今日が最後のブログになります。

ま、出せるもんは出しておけ、ということで準備を進めてきたのですが、Crocos社内で使っていた Wiki ツールを公開します。 実は前からしてたんですがw、もうちょっとアレコレこうしてからバーンと公開しよー！と思っていたらなんかバタバタしてるうちに開発あまり進まなかったので(ありがち)、結局いろいろ道半ば状態ですが、一旦バーンとしちゃいますw

この先はきっと趣味で色々開発をすすめるかと。

Crowi - The Simple & Powerful Communication Tool Based on Wiki

crowi/crowi - GitHub

Crowi Demo and Docs

Crowi

設計思想は「コミュニケーションツールとしてのWiki」です。

大事にしていることは シンプルであること。

読み方は「クロウウィ」です。由来はもちろん、Crocos Wiki ですw 開発を始めたきっかけですが、創業した年の年末年始休みで

ドキュメントを共有したいがまともなWikiツールがない (当時はとりあえずRedmineのWikiをつかってました)

Node.js で遊んでみたい

くらいの感じで、最初3日くらいで形をつくりました。 最初のバージョンは、非常に中途半端でアレだったんですが、わりと使えちゃうから1年半位放置したまま運用してて、とはいえもっと色んな機能つけたい、便利にしたいと本腰いれてやりはじめ、ボチボチとデザインを変えたり機能を追加してきて ... 今に至る、というかんじです。

コミュニケーションツールとしての Wiki

現在のクロコスでは、すべてのコミュニケーションのベースに、Wiki を据えたいと思い、こうしたツールに明るいエンジニア職の人以外にも積極的に使ってもらえるように推進してきました。

ミーティングのアジェンダと議事録の共有

日々のメモ書き

技術仕様のドキュメント

ちょっとしたプレゼンテーション

などなど...

特に、Wikiに情報を載せていくこと徹底する前は、「以前話したことがあると思うんだけど、いつだっけ」といった、意思決定の根拠が残らず、確認をしたり、同じことをまた話したりする無駄がありましたが

口頭で話したことも必ずWikiに書く

書いた後「こんな話でしたよね」とチャットで共有

というフローが身についてからは、認識のズレ (話した時は「あーそうだよね、うんうん」とお互いなったのに、書き起こしてみたら認識違っていたみたいなこと) がなくなったり、後から見返せるようになったりなど、情報がよく回るようになりました。

主な機能

せっかくなので紹介しておきます。

Markdown で書く＆リアルタイムプレビュー

まず、記法ですが、昔であればはてな記法とかPukiWiki記法とかいろいろありましたが、方言含めやっぱりグローバルに Markdown で間違いないでしょ、という感じなので、当然 Markdown で書けるようになっています。 (そういや Wiki の当初のバージョンでは、Markdownにくわえ、はてな記法とRawテキスト の3種類をサポートしてましたが、やめちゃいました)

リアルタイムプレビューというほどでもないですが、横に一応プレビューも出ます。

リスト表示とタイムライン表示

一番こだわったのはここで、 / で終わるページが必ずリストビューになっています。 /user/ にアクセスすれば /user/sotarok や /user/yudoufu などの下層ページが自動的にリストされます。 リストとページを行ったり来たりして、遡れたり掘れたり、というのが気持ちよく出来るように考えました。

/どこそこ/2014/10/31/ほげほげ といった形でページを作成しておけば、

/どこそこ/ にアクセスすればどこそこの記事一覧が、

/どこそこ/2014/ にアクセスすれば2014年に書いたどこそこの記事一覧が、

/どこそこ/2014/10/ にアクセスすれば2014年10月に書いたどこそこの記事一覧が、

表示される、みたいなイメージです。これが一番好きなところです。

また、リストページでタイムライン表示では、それを展開できるようにしました。ページを廻らなくても見られるようにですね。

また、これは副産物的に出来たのですが、 /user/.+/日報/ といった正規表現を含むURLでアクセスすると、例えばこの例であれば全員の日報一覧を出す、などの仕掛けもあります。 はたして便利なのかわかりませんがw、とりあえず日報一覧、くらいの活用はしています。

まだダサイのでデザインとかはまだ色々考えています。^^;

「今日のメモ」

右上から「今日のメモ」をクリックすると、 /user/sotarok/2014/10/31/xxxxx のようなページにすぐジャンプできるようになります。 今議事録を書きたい、今メモをかきたい、といったときのクイックな行動を促せるように設計しました。

見た人とかお気に入りとかいいねとか

意外と「見た人」機能が便利です。 見た人がアイコンとして並ぶことで、「共有したあの議事録見てくれた？」のようなことはすぐにわかるようになりましたし、他の人が書いてくれたメモやアイデアに、何も言わなくても「見たよ」といえるようになります。

あといいね！も実装してあります。 日報にいいね！、議事録にいいね！、アイデアにいいね！、どんどんつければ良いと思います。

お気に入り機能は、お気に入りにいれたやつの変更を追えたり、ブックマーク的にあとで探せたりとかしたい！と思ってつけました。 ちなみに お気に入りはまだ「みる画面」がありません (大笑 えー、がんばりますw

FacebookログインとかGoogle Appsログインとか

一応、設定すればできるようになっております。 最初は Facebook ログインでつかえる Wiki！みたいに始めたんですが、結局Facebookの仕様変更に追従するの面倒になって、ログインくらいはできるけどね、くらいの実装になっています。

Google Apps ログインは、Google Apps 使ってる企業とかだと使いやすいかもねえ！？

競合検知とか、プレゼンモードとか、なんか諸々

WebSocket でリアルタイムで他の人が変更を加えたことがわかったり ... Markdown で書けば勝手にプレゼンになったりとか ... (まぁ reveal.js つかってるだけだけど)

いろいろ中途半端ですが、まあw

裏側とか

いちおう Heroku で動くよねってところを意識して作ってあります。

Node.js

MongoDB

Express 3

S3とか ... AWS 系の諸々とか ...

Socket.IO とか？全部書くの？

パーサーは marked です

(crowi-search は groonga。そのうちこの2プロダクトは統合しよう .......)

どういうノリで書けば良いかわかりませんがまあ、こういう感じのツールになっています。

やりたいことはたくさん

ページのコメント

階層構造の表現をもっと自動で色々やりたい

リストの見た目もなー

画像とかはそもそもアップロードしたい

通知機能欲しいよねとか、

Diff やっぱほしいな

ページステータスとか！、

GitHubの [ ] のチェック記法とか

emoji とか

そういや Angular 化しようとおもってた

コミュニケーションツールとしてもうちょっとちゃんとしたものにするためにはまだまだやりたいことたくさんあります。 アイデアをまとめるのはこっちのデモ代わりに建てた Wiki でやっていこうと思います。

Crowi Demo and Docs

/Crowi

まあ、まだ正直バグもあるしw、手放しにオススメできるかというと、PukiWikiとかを使うくらいならこっちのほうがいいよ、程度ではありますが、今のところ人柱と協力者は募集しておりますw

最後に

カッチョイイロゴを考えてくれた @misuyumi、クロコス退職後某社CTOとなって Pull Request を送ってくれる @riaf、皆さんに感謝！ あとかっちょいいサイトが簡単につくれる Strikingly にも感謝。

それでは、次回どこかでお会いしましょう。

最後の最後に

Good bye Crocos!

[crocos]

クロコスへ出向してみて感じたいくつかのこと

はじめまして。クロコスの藤田です。 本日はクロコスとしての最終日ということで、ヤフーからクロコスへ出向しているエンジニア（私も含め）3人が、クロコスでの経験を通して感じたことを徒然と書いていきたいと思います。 普段のエンジニアブログの内容と少しかけ離れてしまうかもしれませんが、ご興味ありましたらお付き合い下さい。

出向エンジニア3人の紹介

藤田

エンジニア歴10年くらい。クロコスへは2013年の1月にjoin

竹谷

2005年に新卒入社。クロコスへは2013年1月にjoin

佐藤

2007年に新卒入社。クロコスへは2013年10月にjoin

なぜクロコスに入ったか

藤田

クロコスって言えば、PHP界隈では有名だったので、中の人たちはどんな人なのか、それに大企業とベンチャー？での開発の仕方の違いみたいなものを感じたかったというのが大きな理由です。

竹谷

前の部署が大人数の組織で、ユーザーの声が聞こえないというか、何のためにサービスを作っているのかわからなくなったので、小さい組織に行きたくてクロコスを選びました。

佐藤

仕事でちょうどgitやFuelPHPなどそれまで使っていなかった技術をさわり始めていた頃で、トレンドの技術を身に付けられてエンジニアとして成長できそうということでクロコスを希望しました。

入ってみてどうだったか

藤田

意思決定が早いなーと。組織が小さいからっていうのもあると思うのですが、やろうって決めて責任を取る人がいるかどうかってとこが大事なのかなと感じました。

竹谷

意識が高いというか、新しいことを取り入れようとする気持ちが強いなと思いました。常に探っている感じがしますね。入ったときはGITLAB 使っていたんですけど、@sotarokが GitHub の勉強会に行って、GitHub に変更になったこととかありました。

佐藤

ヤフーとは全然違うスピード感でしたし、みなさん凄腕のエンジニアばっかりで付いていけるか不安でした。本当に一から勉強する心持ちでした。

エンジニアリングについて

藤田

基本的にレベルが高いのでうかつなコードが書けないと思いました。気にしてたけどまぁいいやって書いたところにはしっかりツッコミが入るｗ

竹谷

コードレビューがしっかりしていてすごいなと思いました。最初(今でも)、フルボッコでした。プルリクエストの書き方は勉強になりました。

佐藤

Gitを基準にした開発フローは本当にいいなと。コーディングからデプロイまでほぼシームレスになっている。あとはなるべく自動化していく文化。

クロコスの良かった点

藤田

理不尽なことが基本的になかったかな。それも自分の心持ち次第ってところはありますけど。

竹谷

小さなチーム。2人ないしは3人のチームで開発を回していくのはすごく良かったですね。すぐに相談ができて、やることもすぐに決まる。

佐藤

エンジニアにとって最良の環境は何かを常に考えている。何か良いものがあれば、それまで慣れ親しんでいたものでもすっぱり切ったりする。入った時と今とで使っているツールがガラッと変わってます。

まとめ

小さいチームいいね

意思決定は早い方がいいね

エンジニアは最新の技術に触れよう

パーフェクトPHP読もう

きて良かったね

というわけで、様々なクロコスの文化が出てきましたが、出向を通して経験したことを今度はヤフーに還元していけるよう、クロコスのメンバー達と一緒にまた新しいことに挑戦していきたいと思います。

[crocos]

【Emacs24.4リリース記念】いま使っているEmacsのPHP開発環境

クロコスでは生息数が少ない Emacs 派の @suzuki です。

Emacs 24.4 がリリースされましたね。エディタのくせにブラウザが内蔵されたと話題になっていますが、ちょっとした使い方は「Emacs 24.4 の新機能・内蔵ブラウザ eww.el を調べてみた」という個人の日記を過去に書いていたので、参考にしてみてください（宣伝）

さて、今回は、私の Emacs 環境の紹介をしたいと思います。使っているパッケージの全てを紹介すると今日だけでは終わらないので、PHP での開発で主に使っているものを紹介します。

Emacs 環境

Emacs 24.4 (どこかのタイミングのHEAD)

Emacs 25.0 (どこかのタイミングのHEAD)

Emacs 本体は Homebrew を使ってインストールしています。2つのバージョンを書いているのは、現在2台のマシンを使っており、それぞれで利用しているバージョンが違っているからです。今後は 25.0 (HEAD) をメインに使っていこうと考えています。

HEAD だと、いきなり落ちることもあるのですが、まぁ、そこはこまめな保存と Emacs 愛でカバーしています（笑）

利用している Emacs Lisp パッケージ

Emacs Lisp のパッケージ管理には Cask を利用しています。Cask そのものは Homebrew でインストールしています。

Cask 用の設定ファイルはこんな感じです。普段使っているものをそのまま上げてみました。

(source gnu) (source melpa) (depends-on "auto-complete") (depends-on "auto-complete-rst") (depends-on "auto-install") (depends-on "coffee-mode") (depends-on "color-moccur") (depends-on "dash-at-point") (depends-on "editorconfig") (depends-on "es-mode") (depends-on "exec-path-from-shell") (depends-on "google-translate") (depends-on "haml-mode") (depends-on "helm") (depends-on "helm-ag") (depends-on "helm-c-moccur") (depends-on "helm-c-yasnippet") (depends-on "helm-dash") (depends-on "helm-git") (depends-on "helm-git-grep") (depends-on "helm-gtags") (depends-on "helm-ls-git") (depends-on "helm-migemo") (depends-on "helm-package") (depends-on "hive") (depends-on "init-loader") (depends-on "js3-mode") (depends-on "json-mode") (depends-on "less-css-mode") (depends-on "magit") (depends-on "magit-tramp") (depends-on "markdown-mode") (depends-on "mew") (depends-on "migemo") (depends-on "mkdown") (depends-on "multi-term") (depends-on "php-mode") (depends-on "popup") (depends-on "powerline") (depends-on "rainbow-mode") (depends-on "review-mode") (depends-on "rvm") (depends-on "shell-pop") (depends-on "simple-rtm") (depends-on "sql-indent") (depends-on "swift-mode") (depends-on "ucs-utils") (depends-on "unicode-fonts") (depends-on "w3m") (depends-on "web-beautify") (depends-on "web-mode") (depends-on "yaml-mode") (depends-on "yasnippet") ;; php-completion (depends-on "php-completion" :git "https://github.com/suzuki/php-completion.git" :branch "develop" :files ("*.el" "phpcmp-index-of-*"))

PHP の開発に関連する主なパッケージの紹介

Cask ではたくさんパッケージをインストールしていますが、PHP の開発に関連する主なパッケージを紹介します。

auto-complete

php-mode

php-completion

helm

helm-gtags

web-mode

auto-complete はキーワードの自動補完をするためのツールです。Emacs 本体でも dabbrev-expand (M-/) などを使って、キーワードの補完ができますが、それをもっと使いやすくするためのベースツールと言ったところです。

auto-complete では補完候補がポップアップ表示されます。イマドキの IDE などでは、補完候補のポップアップ表示など珍しくないと思いますが、Emacs の世界ではこれだけでも若干モダンに見えるのです。

php-mode は、Emacs で PHP を書く人なら、ほとんどの人が使っているのではないかと思います。PHP のキーワードや関数のシンタックスハイライト（色付け）や、インデントの処理などを行なうものです。

php-completion は、auto-complete と組み合わせて PHP の予約語や関数名などを補完するために使っています。このパッケージだけ MELPA などで配布されているものではなく、自分で改造しているバージョンを使っています（前述の Cask 設定ファイルの最後に書いてあります）。

オリジナルは https://github.com/imakado/php-completion にあるのですが、Emacs 24.3 以降だとうまく動かなかったり、後述の Helm に対応していなかったので、しばらく前に pull request を送ったのですが、残念ながら今のところ反応を頂けていません。

それならばと、自分で fork し、そのパッチを取り込みました。また、PHP 5.4 以上で取り込まれたキーワードや関数（例えば trait や array_column など）を補完できるように辞書を追加する修正を行なっています。

auto-complete, php-mode, php-completion を組み合わせると、次のようなインターフェイスになります。

ちょっとだけモダンな IDE っぽくなりますね。

次は helm と helm-gtags です。

helm そのものは、いろいろなところで統一的なインターフェイスで補完・選択を行なうためのベースツールです。言葉ではうまく伝えられないので、試しにインストールして使ってみるのが良いと思います（文章から逃げた）

helm-gtags は、gtags (GNU global) での検索結果を helm インターフェイスで操作するためのツールです。

Symfony2 などで開発していると、「このメソッドはどのファイルのどこで定義しているのか？」を手動で探すのは非常に困難です。namespace の定義からディレクトリ位置を把握して、ファイルを開いて、ファイル内検索して、、、などとやるのはスピード感に欠けますし、grep や ag (the silver searcher) で検索して探すのもちょっと面倒です。

そんな時の解決策のひとつとして、gtags を使います。開発中のプロジェクトごとに次のようにして「タグファイル」を作成してから利用します。

% gtags

実行したディレクトリ以下のファイルのクラス名やメソッド名が GTAGS や GPATH などのタグファイルに書き出されます。これらのタグファイルは自動で更新されないため、私の場合は次のようなシェルスクリプトを作成し、cron で定期的な再作成をしています。

#!/bin/sh HOME="/home/suzuki" WORK="$HOME/work" GTAGS="/usr/bin/gtags" TARGETS="$WORK/project-a $WORK/project-b $WORK/project-c " for T in $TARGETS do cd $T rm -f {GPATH,GRTAGS,GSYMS,GPATH} $GTAGS --gtagsconf=$T/gtags.conf --quiet done

話を helm-gtags に戻します。このパッケージを使うと次のようにクラス（下の例では ParseException ）名にカーソルを合わせて、M-x helm-gtags-find-tag（私は M-t にキーバインド）を実行すると、そのクラスを定義しているところへジャンプすることができます。

逆にそのクラス（ParseException）を呼び出しているところへジャンプすることもできます。ジャンプするときに複数箇所の候補がある場合には、helm のインターフェイスで選択することができます。

最後は web-mode です。これは主に Twig ファイルを編集するときに使っています。web-mode そのものは、CSS や JavaScript が混在した HTML を編集するときに活躍するツールです。

HTML や CSS のシンタックスハイライト（色付け）やインデントを行なってくれますし、更に Twig や Smarty などのテンプレート言語にも対応しています。

いま Emacs で Web 系の開発をするなら、コレを外してはいけないんじゃないかと思っています。

毎日のようにアップデートされているので、ときどきおかしな挙動をすることもありますが、バグ報告をしたらすぐに直して貰えました。

以上がそれぞれのパッケージの簡単な解説です。

普通ならここから各パッケージの設定について書くのですが、、、ちょっともう長くなってしまったので、これでおしまいにします。リクエストがあれば、ここではないどこかで続き（設定とか？）を書くかも知れません。

イマドキの IDE なら「こんなの標準だけど？」という内容かも知れませんが、もしも Emacs を使いつつ、まだこれらのパッケージを使ったことがない方がいらしたら、ぜひ一度試してみてください。

おわりに

実は（？）会社組織としてのクロコスは残すところ本日のみ（！）です。会社としてお世話になったところもあれば、個人としてお世話になった方々もたくさんいらっしゃいます。

私は会社の代表でもなんでもないのですが、ここで改めてみなさんへお礼を言いたいと思います。

ありがとうございました！ そして今後ともよろしくお願いします！！

[crocos]

Grunt でファイルの変更を watch して PHPUnit を自動実行する（拡張版）

はじめまして、2013年1月からクロコスで働いている @suzuki です。 入社してから、まだ一度もエンジニアブログを書いてなかったので、いまごろ慌てて書いています。

下記の内容は、個人の Web 日記で書いた『PHPUnit のテストファイルを Grunt で監視して「変更があったファイルのテスト自動実行」ができるようになるまでの記録』に続く内容です。

日記内で書いていた内容から少し拡張して、クロコス内で使うようにしたので、その記録になります。

ちなみに Grunt やプラグインなどのインストールについては記述していませんので、世の中にある他の記事などを参照してください。

前提

もともとクロコスでは、LESS から CSS への変換・結合や、JavaScript の minify などに Grunt を使っていました。

普段は watch タスクを実行して、LESS や JavaScript ファイルを監視し、変更が発生したら即座に CSS / minify 化を自動実行して、ブラウザ等で確認するという開発スタイルがあったのです。

% grunt watch

この「監視して自動実行」の流れに PHPUnit も組み込めたら楽なのかな！と思って実験してみた結果が前述の Web 日記です。

課題

先の日記の方法では「テストケースファイルに変更があったら、そのファイルのみを対象としてテストを自動実行する」という要望はクリアできていましたが、今度は「テストケース以外のファイルが更新した場合も、そのファイルの対となるテストケースを自動実行する」という動作が欲しくなりました。

また「何かのファイルが更新されたら、全てのテストを自動実行して欲しい」というリクエストも社内から出てきました。

この2つの課題について対応ができたので、ここに記録として残しておきます。

ファイル構成

アプリケーションのファイル構成

アプリケーションのファイル構成は、おおまかに次のようになっています。

PROJECT_HOME/src/Crocos/BarBundle/ PROJECT_HOME/src/Crocos/BarBundle/Tests/ PROJECT_HOME/src/Crocos/FooBundle/ PROJECT_HOME/src/Crocos/FooBundle/Tests/

例えば、Baz という Entity があった場合は、テストケースファイルを次のような配置にしています。なお、ここからは PROJECT_HOME は外して表記します。

src/Crocos/FooBundle/Entity/Baz.php src/Crocos/FooBundle/Tests/Entity/BazTest.php

Baz.php というファイルと、そのテストケースのファイル BazTest.php の関係は「Tests」ディレクトリが間に挟まり、ファイル拡張子の前に「Test」という文字列が入っている形になります。

Grunt の設定ファイルの構成

個人で勉強していたときは Grunt の設定ファイルに JavaScript を使っていたのですが、クロコスでの設定ファイルは CoffeeScript を使っています。

Gruntfile.coffee _grunt/grunt-watch.coffee _grunt/grunt-phpunit.coffee

ベースとなる Gruntfile.coffee と、そのファイルから読み込まれる個別の設定ファイル grunt-watch.coffee と grunt-phpunit.coffee という構成です。名前から想像が付くと思いますが、それぞれ grunt-contrib-watch と grunt-phpunit プラグインの設定ファイルになっています。

設定ファイルの中身

Gruntfile.coffee

module.exports = (grunt) -> 'use strict' grunt.initConfig grunt.loadTasks '_grunt' grunt.registerTask 'default', ['watch']

grunt.loadTasks で _grunt ディレクトリ以下のファイルを読み込むようにしています。

grunt.registerTask の default に watch を定義しておくことによって、実行タスク名を省略した時でも watch タスクが実行されるようにしています。

会社のプロジェクトで実際に使っている Gruntfile.coffee には、LESS や JavaScript 用のタスクもここに設定していますが、解説をシンプルにするため、ここでは省略版で掲載しています。

_grunt/grunt-phpunit.coffee

module.exports = (grunt) -> 'use strict' grunt.config 'phpunit', classes: dir: 'src/Crocos' options: bin: 'bin/phpunit' configuration: 'app/phpunit.xml' grunt.loadNpmTasks 'grunt-phpunit'

classes.dir には、PHPUnit のテスト実行対象のディレクトリを指定しておきます。こうしておくと、次のようい phpunit というタスク名で grunt を実行した場合のデフォルトとして利用されます。

% grunt phpunit

PHPUnit の設定は app/phpunit.xml に記述しています。これは、Grunt で利用する前から作成していたもので、次のように phpunit コマンドを実行する際にも使っている PHPUnit の標準的な設定ファイルです。

% phpunit -c app/phpunit.xml

このファイル名を options.configuration へ指定しています。

_grunt/grunt-watch.coffee

module.exports = (grunt) -> 'use strict' options = {} options['phpunit'] = files: ['src/Crocos/**/*.php'] tasks: ['phpunit'] options: spawn: false grunt.config 'watch', options phpunitOption = grunt.option('phpunit') if phpunitOption == undefined phpunitOption = 'no-db' grunt.event.on 'watch', (action, path, target) -> if target is 'phpunit' switch phpunitOption when 'no-db' # execute exclude 'db' group grunt.config.set 'phpunit.options.excludeGroup', 'db' when 'single' # execute only target file if /Test\.php$/.test(path) grunt.config.set 'phpunit.classes.dir', path else if match = /^(src\/Crocos\/.+Bundle\/)(.*\/)([^\/]+)(\.php)$/.exec(path) bundle = match[1] dir = match[2] name = match[3] extention = match[4] testCaseFile = bundle + 'Tests/' + dir + name + 'Test' + extention grunt.config.set 'phpunit.classes.dir', testCaseFile else console.log "Can't parse path" when 'all' # esecute all testcases else # execute all testcases grunt.loadNpmTasks 'grunt-contrib-watch'

まず watch するターゲットなどの設定です。src/Crocos/**/*.php のファイルを監視対象としています。監視対象ファイルの変更を検知したら、phpunit タスクを実行するという設定になっています。

さらに watch のイベントが発火した場合の設定（grunt.event.on 'watch'）を追加しています。イベントが発火した場合かつタスクのターゲットが phpunit だった場合に以下の処理を行ないます。

--phpunit オプションの内容によって動作を変更

all の場合は、全てのテストケースを実行

no-db の場合は、全てのテストケースからデータベース依存のテストを除外して実行

single の場合は、変更があったファイルに対応するテストケースのみ実行

all は、特殊な処理はしておらず、そのまま全て実行しています。それ以外の no-db と single に関しては、grunt-phpunit の実行前に config を書き換えるという技（？）を使ってテスト実行対象ファイルを指定しています。

no-db が指定された場合には、phpunit.options.excludeGroup に db を設定しています。

phpunit.options.excludeGroup は grunt-phpunit プラグインのオプションで、指定した @group アノテーションを除外する動作になります。

クロコスのテストケースの「@group db」とは「テスト実行にデータベースを使うもの」としています。なぜこのような指定を入れたかと言うと、、、全テストが遅いからにほかなりません。

データベースを使うテストを含めて全実行すると、そこそこ時間がかかってしまっています。「コード修正→テスト→コード修正→テスト」という作業をリズミカルに行うには、この遅さが致命的でした。

本来ならテストをリファクタリングして高速化するのが本筋ではあるのですが、、、いろいろな要素を考慮に入れた結果「コード修正時の全テストからはデータベース依存のテストを抜いておく」のが一番バランスが良いと判断しました。

あ、ちなみに「遅いテスト」の大部分を書いた張本人が私です。1年前の自分の力量ではこんなテストしか書けませんでした。。。

次に single オプションの設定内容です。

ここは少々強引に書いていて、Test.php というファイル名なら、そのファイルをテスト対象にし、それ以外の PHP ファイルであれば、*Bundle/ 以下のディレクトリ名を取得して *Bundle/Tests/ に加工し、さらに Test をファイル名に加え、テスト対象のファイル名を作成しています（src/Crocos/FooBundle/Entity/Baz.php であれば src/Crocos/FooBundle/Tests/Entity/BazTest.php のように）。

ディレクトリ名やファイル名は正規表現でマッチさせて加工しているので、想定していないパターンがあると正しく動かないのですが、今のところ（おそらく）問題なく動いていると思います。

さらに、先ほども少し出てきた phpunit.classes.dir（PHPUnit のテスト対象ディレクトリ名）を上記で作成したファイル名を grunt.config.set で書き換えています。

no-db と single の動作イメージ

no-db の動作イメージ

single の動作イメージ

まとめ

設定を並べただけで、面白みのない記事になってしまいましたが、現在もこれをベースにした Gruntfile.coffee を使って運用しています。ちなみに私は single の動作が好きなので、それを多用しています。

最後に、これまでの設定・運用においての KPT を書いて、終わりにしようと思います。

Keep

テストの自動実行はとてもラクだし、楽しい

コーディングとテストのリズムが良くなる

Problem

データベース依存のテストが遅い

no-db にしても、まだ全テストは遅い

正規表現周辺の処理がベタベタでカッコ悪い

Try

データベース依存テストの最適化

テスト実行の並列化

Grunt 経由ではないが paratest を使ってみたことはある

これをうまく活用できないか？

では、また！

[crocos]

Pull Request のフォーマットを決めるとレビューの効率が3倍よくなる

あけましておめでとうございます ....

と、この下書きの先頭に書いてありましたので、この記事を書き始めてから、こちらもすでに9ヶ月以上が経過しております。今年ももう後半戦入っておりますが、ベリースローペースでがんばらせていただきます。

そうこうしているうちに、株式会社クロコスの、ヤフーへの吸収合併が発表されました。 この媒体で記事を出すことは、もうあと何回もないかとは思いますが、皆様これからも変わらず、よろしくお願いします。

さて、そういうわけで。

長くなるので先に結論

Pull Request でレビューするとき、レビューを提出する文書フォーマットを決めておくと非常に捗る

レビューが早くでき、

レビューの質があがり、

ハッピー

Pull Request のレビューについて

本題です。

前提条件:

基本的には、OSS 等ではなく、業務で利用する GitHub を想定しています。

(もちろん OSS に当てはめても良いとは思いますが、OSS の場合は、より Pull Request を受け取るハードルを下げる方向のほうが、全体的には活発になって良いのかな、と思います。もちろんレビュワーは大変ですが。そこはそのソフトウェアの開発ポリシーによりますかね)

開発には常に Pull Request を利用していて、メインブランチへの merge 前に必ず Pull Request によるレビューを行うものとします

その上で、どのようにレビューをしたら効率が良いか (レビュワーにとって負荷が少なく、漏れが少なく、効果的で、効率的) を考えます

実際に運用しているうちの環境としては、

開発チームを、リーダー1人 + メンバー2-4人程度の小規模なチームを保持

Pull Request のレビューは以下の体制で行っています

チームリーダーが行う

リーダーのコードは、リーダー同士でチェックする (都度「XXさんこれ見てください」のように依頼してる)

最低1人以上から「:+1:」コメントがつくと merge 可能

大きなブランチはなるべく作らない。大きくなりそうなときはリリースを分割したり、サブブランチに分割したりする。

また、本稿の背景にある考え方として、以下の記事が非常に参考になりましたので、是非一度読んでみてください。

コードレビューを円滑に行いたい #cross2014 のお話

Pull Request のフォーマットって？

フォーマットとは、Pull Request を作る際の説明のテンプレート/ルール です。

具体的に見ないと、イメージが湧かないと思うので、うちで使っているテンプレートの1つの例をみてみます。

## 関連URL * WikiのURL(Markdown形式)や ... * 画像URL や ... * 操作可能な画面のURLや ... * (あれば...) ... ## 概要 * なぜこの変更をするのか、 * 課題は何か、 * これによってどう解決されるのか、 * など、この変更に対する概要を記載 ## 影響範囲・ターゲットユーザ * 主催者へのメリット・デメリット * 応募者へのメリット・デメリット * その他のユーザへのメリット・デメリット ## 技術的変更点概要 * なにをどう変更したか * ロジックがどういう手順で動くのか、 * DBからどういうクエリで何をとってそれに何を処理するのか、 * などなど、 * レビュワーにわかるように、技術的視線での変更概要説明 ## 使い方 * 使い方の説明 * 再現条件 (例えば、いいねの状態、デバイスの状態、プランの状態や、設定によってこういう風に使える、とかこういう画面が出てくる、とか条件があれば) ## UIに対する変更 * 変更前のスクリーンショット * 変更後のスクリーンショット ## マイグレーション * マイグレーションが必要な場合、`ALTER TABLE` 等を記載する 記入例: ```sql ALTER TABLE message_send ADD body_replacements ... ``` ## クエリに対する変更 * 変更されるクエリ (変更前、変更後) * 新規に追加されるクエリ * 観点: * WHERE句に指定した条件の index 設計は適切か * 想定される対象のデータ量 * 想定されるデータ量が大量のとき大丈夫か (ダメな場合、いつまでにどうにかする予定があるのか、忘れないために別チケットを用意したか) ## 個人情報の取り扱いに変更のあるリリースか * メールアドレスや住所情報等、個人情報にあたるものを新規に保存する場合、ドキュメントを書き、そこへのリンクを貼る ## TDログ 重要な機能を追加・変更した場合、ログを仕込む必要があるか、ログが入っているか、入れているログが変更によって漏れていないかなどを確認する必要があります。 * [ ] 重要な機能であり、ログを仕込んだ (説明用Wikiへのリンク) * [ ] ログを入れる必要ナシ ## テスト結果とテスト項目 * [ ] テストする際の項目を、このように、チェック可能な形式で記載する。 * [ ] テストしたらチェックを入れていく。(staging でテスト、など出ない場合、基本すべてのチェックが終わった時点でレビューに入る) * [ ] 特に、PC、モバイルの違い、応募フローの再現手順など、できるだけ広い視野で。 * [ ] 詳しくは、テスト観点リストも参照のこと。 * [ ] できれば、**開発した人以外が** 項目を洗い出してください。(開発者本人は、盲目的になっている可能性があります) * [ ] 機能のON/OFF によって画面の出しわけ、機能が有効になったり無効になったりする場合、場合分けしてテスト項目を書く * [ ] 他チームへテストを依頼した場合はチーム名書いておこう * [ ] それをテストしたチームの人が、チェックを入れよう ## 今回保留した項目とTODOリスト 箇条書きで書く。できれば次のチケットを作る。 * あれこれを治す #xxxxxx * あれそれを実装する #xxxxxx ## 共有先 ↓ 共有したい先にチェックをいれてください。 merge 時 `HipChat: 部屋 @sotarok` などを記載すると、共有時に自動的に mention もつけてくれます。 記法: `HipChat: 部屋 @sotarok` 社内共有: * [ ] HipChat: Crocos ALL * [ ] HipChat: リリース情報 * [ ] HipChat: 開発 * [ ] HipChat: グロースx開発 * [ ] HipChat: 営業x開発グロース * [ ] HipChat: サポート * [ ] メールで共有: (ここにメールアドレスを記載) 社外アナウンス (上から大きい順): * [ ] プレスリリース * [ ] 告知用ページ作成 (w/ グロース) * [ ] 事前メールアナウンス (internal のアナウンス機能で) * [ ] Facebookページでアナウンス * [ ] アナウンス無し ## その他 * レビュワーに対する注意点 (ここはこういう風に思ったけどこういう風に実装した、ここはこうしようと思ったんだけどこういう悩みがありやめた、など注意点があれば) * リリースに対する注意点 (その他)

上記フォーマットは、「機能追加・機能変更系」のための Pull Request のフォーマットです。 これは社内の Wiki に置いてあって、Pull Request を送るときに↑からフォーマットをコピーして中身を埋めて(変更したり削ったりして)、Pull Request を送信する、という流れになっています。

フォーマットの内容にどういうことを書くのか、というのは、フォーマットの定義自体に解説が書いてありますので大丈夫ですかね。

ちなみに、このフォーマット中にある テスト とは、ユニットテストではなく、ファンクショナルな、人力テストということです。 コードレベルでの保証は自動テストで行ったほうが良いでしょう。クロコスの場合は、Pull Request ごとに Jenkins のテスト結果が Pull Request 上に表示されているため、まあこちらは問題がありません。

Pull Request のタイトル

タイトルはフォーマットに記載していないのですが、以下のようにルールづけています。

変更の内容が他の人にも伝わるように1行でまとめる。エンジニア以外が見ても分かる内容にする。

さて、これにそって記入後、ペロっと GitHub に貼れば、もちろん Markdown 形式なのでフォーマットされて表示されます。素敵で便利ですね。

フォーマットの種類

以下の6通りのフォーマットを用意していて、それぞれ多少項目が違ったりします。(例えば、フロントエンドのみの変更では、技術的解説欄はなかったり、不具合修正系には障害報へのリンクや影響範囲の詳細調査結果などの内容があったり、など)

機能追加・機能変更系

リファクタ・構造の変更・基盤開発系

不具合修正系

あるPRの修正PR

小さな変更

フロントエンドのみの変更

フォーマットを定義するメリット

上記フォーマットをみてもらうと分かる通り、結構盛りだくさんですが、このようにフォーマットを決めておくと、

レビュイー (Pull Request を送る方) にとっては:

レビュワーに 何を見てほしいか が明確になる

その機能が利用者に何をもたらすかというプロダクト視点を育てる

Pull Request を堤出する人による観点のズレが減る

この変更について、事前に把握しているか/いないか、あるいはコード対象コードを見たことがあるか/ないか、などレビュワーにもそのコードへの精通度合いが違います

その違いを吸収し、ある程度、だれでもレビューできるようになります (もちろんコーディングや設計のレベルとしてエンジニアとしての一定のレベルは必要。)

リリース前後の手順の確認

何をテストしたのを明確にする、テストをさぼらない

レビュワーにとっては:

何をレビューすれば良いか が明確になる

この変更によって何が変わるのか、何が行われるのか、その理由もinputできる

変更前後の画像が添付されるためひと目でわかる

UIのどこが変わったのかが明確になり、そこから影響範囲の想像力を働かせるうえでも役に立つ

関連文書 (Wiki などに書かれたドキュメントや、申請系) にすぐアクセスできる

何をテストしてくれたのかがわかる

例えば、「ここを変更すると、ここにも影響範囲がありそうだな、ここってテストしたのかな」等、フォーマットが導入される前は、聞いてみて「あ、それもテストしました」というやりとりもありましたが、今では、何をテストしていて、何をテストしていないのかがすぐわかるため、コミュニケーションコストの軽減にもなります

その他のメリット

フォーマットにそって記載されていると、Parsability が上がるということもメリットの一つとしてあげあられます。 クロコスでは、Pull Request のフォーマットにそってパースされ適宜様々なところへの情報共有に利用されます。

Pull Request マージ時に hook して...

HipChat への通知

どの部屋に通知するのかを指定しておくと、merge hook 時に自動的にフォーマットの中から重要なものだけを抜き出してbot が発言してくれます。 例えばこんなかんじ:

これにより、例えば、営業部から依頼を受けて作業していたものが、「あれの作業って終わりました？」「あ、実は一昨日リリース済みです」のような、共有漏れによるロスがなくなりました。

@sotarok などと記載しておけば、mention も飛ばせます

リリーストピック収集ツール

週1回の全体定例MTGで、今週なにがリリースされたのかを発表する場があるのですが、その際に、注目すべきリリースが何か、後からリリースを振り返らずとも、自動収集でレポートを作ることができます

また、ここで発表される、ということを前提におくと、「Pull Request にかかれている内容が当人にしかわからない」という意味不明なことが少なくなります。(ただし、エンジニア以外にも見られる情報だからね、というのを浸透させるのは少し時間が必要でした ^^; 繰り返し言うこと、が重要です。)

レビュイーが、色々書かなければいけないという、時間的/労力的に大変というデメリットもあります。しかし、そもそもフォーマット自体、「いくら急いでいても、多少大変でも、このレベルは保ちましょう」という一定のガイドラインを設けることでもあり、これを満たせないならば (その会社での/そのチームでの) その人の活躍の場は無いよ、というだけの話であり、まあそれはそれで。

したがって、フォーマットのレベル感といいますか、どのレベルまで書かせるか、というのは、当然

アプリの特性

サービスのステージ (立ち上げ期？成長期？運用期？)

チームの特性

会社のステージ (立ち上げ期？成長期？運用期？)

などによって異なります。

会社やサービスが成長していくにしたがってフォーマット自体の見直しも適宜行っていかなければいけませんね。

例えば、会社の立ち上げ期、エンジニアが3人くらいだとすると、みんなが同じものを作っています。そうすると、お互いの責任範囲や、書いたコードへの理解、作っているものをみんなが共有し、知っている状況ですよね。そういう時は、前提条件となるものの説明などはある程度省けるかと思います。((それでも変更の概要はもちろんあるほうが効率は良いと思いますけどね))

このフォーマット導入後は、3ヶ月に1度くらい、「いまのフォーマットでの不満、過剰な点、内容としてこれも欲しいよ、という点」などをメンバーにヒアリングしていて、それによって既に3-4回の改定が行われています。ルール自体も、陳腐化しないように育てていく必要があります。

フォーマットをうまく運用するコツ

定義しても誰も使ってくれないのでは意味がありません。 まずは、必ずこのフォーマットにそっていなければレビューされない、というのは大前提としてあります。レビュワーにとって非常にメリットがあるため、Pull Request が堤出された段階でこのフォーマットにそっていなかったら突き返す、というのは自然と発生しますw

ただし、色々書くのが面倒、というのを超えるメリットが無ければ、なかなか大変です。 そこで、上の方に書いた、フォーマットにそっていれば、自動でチャットや定例MTGで共有されるといった負荷軽減ができると、理解してもらいやすくなります。

まとめ

Pull Request を送るときの文書フォーマットを決めて運用することで効率が良くなる話をしました！みなさん、お気づきかもしれませんが、タイトルでは「レビューの効率が...」と書きましたが、実は、レビューだけでなく全体の業務や情報共有の効率がめちゃくちゃ良くなるのですよ。

次回は、Pull Request を用いた、半自動リリースのフローについてお話できると良いなーと思います。

[crocos]

ニュージーランドのPHPカンファレンスに参加してきました

こんにちは、@yuchimiriです。

2014年8月27日（水）〜29日（金）に、ニュージランドのウェリントンという街で「New Zealand PHP Conference」が開催されました。

クロコスのエンジニアの多くは毎年東京で開催されている「PHPカンファレンス」のスタッフをしていて、私は今年実行委員長をしているのですが、海外のPHPカンファレンスがどんな雰囲気なのか興味があって参加してきました。

今回はその様子をレポートしたいと思います。半分観光日記です。

まず開催地となったウェリントンはニュージーランドの首都で、オークランドに続き同国2番目の都市です。

南半球にあるので日本とは季節が逆で、今のシーズンはちょうど冬の終わりになります。

UTCは+12で、日本より3時間早いです。

ウェリントンの空港に着いてまず最初に驚いたのは、入国審査カードの入国目的のところで "conference/convention" にチェックを入れてたら、係員の人に「PHPカンファレンスですか？」と聞かれたことです。

空港の人まで知ってるのか...！と少し恐怖したのですが、首都と言っても小さい都市なので「RubyWorld Conferenceのために外国人が出雲空港にたくさんきた」ようなものだと思ったら納得しました。

ウェリントンは海と丘に囲まれた静かな街で、映画に出てきそうなノスタルジックな建物と、近代的な建物が混在しています。

食べ物は欧米的な食事と、海に囲まれているので魚介系のものがメインのようでした。

カンファレンスのスタッフの方に紹介してもらったホテルはとても綺麗で、細かいところまでサービスも行き届いていてとってもよかったです。行く機会があったらぜひ使ってください。

James Cook Hotel Grand Chancellor

Workshop Day

さて本題。

27日（水）は Workshop Dayとして様々なワークショップが開催されました。

Wield AngularJS Like a Pro presented by Nate Abele

Design Patterns presented by Brandon Savage

Getting Started With Laravel 4 presented by Christopher Pitt

Deep dive into the advanced PHP components presented by Joshua Thijssen

私はこの中でAngularJSとLaravel 4のワークショップを受けました。

AngularJS

AngularJSのワークショップでは、簡単なメッセージアプリを作りました。

JavaScriptのフレームワークはBackbone.jsくらいしか触ったことなかったのですが、DIとか使えるのに驚きました。

ちょっと構造が難しくて、覚えるのに時間がかかりそうな感じはしましたが、複雑なアプリケーションを作るときはよさそう。

Laravel 4

Laravelはこのワークショップで初めて触りました。

インストールが簡単で構造も分かりやすく、初心者向けという感じ。artisanというCLIが便利でちょっと感動しました。

ただ自動的に作られるファイルとかでインデントがTabになってたり、ここ改行入れるべきだよねってとこで入ってなかったり、変なとこに空白入ってたりがどうしても気になって、全部直しながらやってたので今後使うかは分かりません...

夜

この日の夜は市内のSilverStripeという開発会社で、カンファレンスのスタッフとスピーカーとの交流会のようなものが開かれました。

私はスピーカーではないのですが、日本のPHPカンファレンスのオーガナイザーとして呼んでいただき、SilverStripeの社員さんとか、シドニーから来ているエンジニアの方々と話したりしました。リラックスムードの交流会で楽しかったなー。

PHPの作者であるRasmus Lerdorf氏も参加されていて、一緒に写真を撮ってもらいました。嬉しい！

1カットが顔より大きいピザ

Main Conference

28日（木）, 29日（金）は メインカンファレンスです。トラックは2本走っていて、好きなセッションを選んで参加するという形式でした。

http://www.phpconference.co.nz/schedule/

プログラムを見てもらうと分かるように、頻繁に長めの休憩時間が設けられています。

Day 1

08:45am - 10:00am：Registration and morning tea

11:15am - 11:35am：Short Break

12:25pm - 01:35pm：Lunch

03:25pm - 04:00pm：Afternoon Tea

05:40pm　　　　　：Conference Social

Day 2

08:00am - 09:00am：Registration and Refreshments

09:50am - 10:20am：Morning Tea

12:10pm - 01:20pm：Lunch

03:10pm - 03:40pm：Afternoon Tea

この時間はロビーにコーヒーとかお菓子とかご飯が用意されていて、それらをつまみつつ参加者同士で交流する時間でした。

エンジニアって結構非コミュのイメージあると思うのですが（私もそう(・ω<)）、あちらのエンジニアの方々はみんな気さくでどんどん周りの人に話しかけててすごいなーって思いました。そういう人たちだからカンファレンスに参加しているのかもしれないけど。

とにかくこの時間が一番大変でしたが、とても勉強になりました。

あと、受付の時に他の人の名前が書いてあるドリンクチケットをランダムで2枚渡されて、本人を探しだして渡さないといけない（でないと、その人がドリンク飲めない(>_<)）っていうミッションがありました。これは面白い試み！

ふたりとも読み方難しくて探すの大変だったのですが、なんとか2枚とも渡すことが出来ました。

私の名前は日本人って分かりやすかったようで、すぐ見つけてもらえました！

カンファレンスの最初に行われるウェルカムノートは、なんとウェリントンの市長さん（カッコイイ女性）でした。 地域をあげてイベントを支援してるということですね、すごい。

あと地元の学校の子達がダンスを踊ってくれたりしてそれはもう可愛かったです...！

私が2日間で参加したセッションは以下になります。 資料もできるだけ集めてみましたので、興味があればどうぞ。

Coding and Dreaming – PHP in 2014 – Keynote - Rasmus Lerdorf

http://talks.php.net/nz14#/

10 warning signs to watch for to prevent project failure - Yann Larrivee

https://speakerdeck.com/ylarrivee/nz-php-10-warning-signs-in-it-projects

Cloud Craft for Spatial Cadets - Katie Miller

http://spatial.codemiller.com/#/

Web Application Security: Winning When The Odds Are Against You - Ben Dechrai

http://www.slideshare.net/ctoforhire/web-application-security-winning-when-the-odds-are-against-you

Scaling PHP in the real world! - Dustin Whittle

https://speakerdeck.com/dustinwhittle/oscon-scaling-php-in-the-real-world

From Zero to Online cafe ordering in 20 minutes - Steven Cooper

http://www.slideshare.net/DeveloperSteve/zero-to-online-cafe-in-20-minutes

Designing Hypermedia APIs with PHP - Nate Abele

https://speakerdeck.com/nateabele/designing-hypermedia-apis

Grown Up PHP - Hamish Friedlander

http://hafriedlander.github.io/grown-up-php-slides/#/

A tale of three languages - Mal Curtis （スライド見つからず）

The first few milliseconds of HTTPS - Joshua Thijssen

https://speakerdeck.com/jaytaph/the-first-few-milliseconds-of-https-phpnz14

Testing your PHP application with Selenium on Travis CI - Yusuke Ando

https://speakerdeck.com/yandod/testing-your-app-with-selenium-on-travis-ci-1

The Seven Deadly Sins of Object Orientation - Brandon Savage （スライド見つからず）

参加してみて圧倒されたのは、スピーカーの皆さんが全員ものすごくプレゼンテーションが上手なこと。 みんなリモコンを使ってステージの上を広く使いながら堂々と発表してるし、緊張とか1ミリも感じませんでした。

セキュリティについてや、プロジェクトの進め方、多言語との併用についてなど、幅広い分野の話がありましたが、 中身的には日本のカンファレンスも負けてないなという印象を持ちました。

あとまだ第一回目のカンファレンスだったからかもしれませんが、みんな真面目な内容で「こ、こいつ変態だー！」っていうのはなかったです。

思ったこととか気づいたこと

ワークショップについて

メインカンファレンスの前にワークショップデーがあるのは海外のカンファレンスだと一般的なようですが、私は英語力の不安などもあったので最初はメインカンファレンスにだけ参加しようと思っていました。

しかし海外のカンファレンスにたくさん参加されている @yando さんに、「絶対ワークショップから出たほうが良いよ」とアドバイスを貰い、参加することにしました。結果的に、本当にそうしてよかったなーと思ってます。

次の日からみっちり英語のプレゼンテーションを聞くことになるので、聞き取りの予習？もできるし、参加者同士で顔見知りもできるし、いいこと尽くめでした。

カンファレンスはエンジニア同士でコミュニケーションを取る場

はじめの方にも書きましたが、参加者同士で交流する機会がかなり多く設けられていました。

慣れるまで大変でしたが、エンジニア同士情報交換したり、知り合いを増やしたりするのにすごく有意義な時間だなと思いました。

これ、日本でやるとどんな感じになるのか、気になります（意外とうまくいくのかな）。

ハンドルネームについて

海外のエンジニアはハンドルネームに本名をつなげたりちょっと省略したものを使うのが普通みたい（yukimaejima みたいな）で、わたしの「yuchimiri」っていうハンドルネームは「え、本名と違うじゃん、なんで？」って言われました。

うちの会社なんてcocoitiとかhebariとか変な名前の人ばっかりなのに。

ウェリントンについて

ウェリントンの人はみんな朝方の生活をしていて、7時代から働いて夕方には家に帰って家族と過ごす文化のようです。

お店も夕方には閉まっちゃうし（ご飯食べるところはあるけど）、平日の夜はあんまり街に人気がないです。

あとどこに行ってもトイレがものすごく綺麗でした。これは本当に感動した。

最後に

1週間で色々大変なこともありましたが、終わってみるとすごくいい経験になったし、行ってよかったなと思っています。

滞在中ずっとフォローしてくださった @yando さん、ありがとうございました！

みなさんも海外のカンファレンスに行けるチャンスがあったら是非チャレンジしてみてください。

あとカンファレンスで知り合った人が作った子犬ちゃんテキストのアプリがマイブームなのでリンクしておきます。猛烈に可愛い。

https://itunes.apple.com/jp/app/puppy-text/id518117988

ところで、今年の日本のPHPカンファレンスは10月11日（土）に蒲田の産業プラザPiOで行われます。

現在絶賛スピーカー募集中です！

http://phpcon.php.gr.jp/w/2014/2014/08/28/call_for_papers/

たくさんのご応募お待ちしております(๑′ᴗ'๑)/

スピーカー以外で参加される方も、現地でお会いしましょう〜(๑′ᴗ'๑)/

[crocos]

クロコスにおけるSymfony2 のお話

はじめまして。クロコスの @okapon_pon です。 メルマガ・データソリューションというチームでアプリケーション開発をしています。

前回、前々回の記事で @yudoufu がブログを書くように急かされている様子が紹介されてましたが、ついに私にも白羽の矢が立ちました。

(；・∀・)

何を書こうかと悩んだのですが、私が日本Symfonyユーザー会の人ということもあり、クロコスにおけるSymfonyの利用について書きたいと思います。

バージョン

私が入社する前の創業初期の頃、クロコスではまだalpha版のSymfony2を利用しはじめたそうです。

長らくSymfony2.0系を利用していましたが、昨年11月に2.0 → 2.3 にガツッとアップグレード。エンジニア総動員でデバッグし乗り切りました。 現在アプリケーションはSymfony2.3系で動作しています。

FWの変更が激しかった頃の利用とあって、アップグレードは大変でしたが、2.3以降のバージョンアップはわりと安定しているようですね。

2.3以降はリリースサイクルに加え、BCに対するリリースポリシーもしっかり明言されているため安心して使えるFWになっていると思います。

【参考】

The Release Process

Our backwards Compatibility Promise

比較的バージョンアップも行いやすいよう配慮されているようですが、今後のアップグレードはというとクロコスでは当面ないのではなかろうかと思います。

FWとしての機能は2.3のままでも十分であり、なかには魅力的な機能追加も含まれていたりはしますが、積極的にアップグレードする動機がないからです。

少なくとも、次のLTSであるSymfony2.7がリリースされるまではないでしょう。

フレームワークの拡張

クロコスにおけるSymfonyの利用ですが、FWを改造して「オレオレFWを作り上げた」というようなことはありません。 それはSymfony自体にいわゆるレールというものがなく、FWに抗うような拡張をする必要がないからです。

SecurityBundleだけは標準のものからCrocosSecurityBundleというものに完全に置き換えています。 シンプルな作りとなっており、標準のものと比べると格段に学習コストは低くなっています。

その他、社内製のバンドルを開発＆利用していますが、それらは機能拡張が主になります。 利用バンドルについては、次節で触れることにします。

標準的な使い方で開発を行っているため、これまでにSymfonyで開発した経験のある人であればすんなり開発を進めることができます。

バンドル

たまに勉強会などで、サードパーティのバンドル何使ってますか？と聞かれることもあります。 その際、返答に非常に困るんですね。

というのもサードパーティ製のバンドル利用はそこまで多くありません。

標準に含まれていないバンドルはというと

KnpPaginatorBundle

StofDoctrineExtensionsBundle

DoctrineFixturesBundle

PsPdfBundle

この４つだけです。

この中で珍しいのは、PsPdfBundleぐらいですね。

名前から推測できると思いますが、PDFファイルを出力する機能を提供してくれるバンドルです。

その他の３つのバンドルは The 30 Most Useful Symfony Bundles (and making them even better に掲載されている有名どころのバンドルなので説明は不要だと思います。

残りはクロコス内製のバンドルになります。その為ほとんどが非公開となっていますが、以下のようなバンドルを使っています。

CrocosSecurityBundle - 標準のSecurityBundleを置き換えることで認証システムを提供

CrocosFrameworkBundle (非公開) - Facebook PHP SDKを統合し、各種Utilityをまとめた社内フレームワーク

CrocosTreasureDataBundle(非公開) - TreasureDataにログを送る仕組みを提供

CrocosHtmlPurifierBundle (非公開) - HTMLタグの入力を許可するフォームを作る場合に利用する便利機能を提供

CrocosQueueBundle (非公開) - Queueシステムを提供

CrocosPaymentBundle (非公開) - WebPayを利用したクレジット決済機能を提供

規模感と開発ルール

Symfonyからは少し話はそれますが、「Crocosマーケティング」というメインのサービスでは、src以下のプロダクションコードの行数はphpファイルだけで約22万行になります。（テストコード除く） ついでにいうと内製のBundleのコード量は、53,000行ほどになります。

8月は夏休みを取っている人も多いのですが、直近１ヶ月の履歴を見ると、125のPull Requestがマージされphpのコードも5,000行ほど純増しています。

これだけのコード量なので全てを把握して開発することは不可能ですが、ビジネスロジックは基本的にサービスクラスに書く、こういう目的のコードはここに置くという（暗黙ではありますが）ルールを設けることで破綻することなく開発が行えています。

Symfonyの開発においてはこう書かなけれならないというものはないので、自分なりのスタイルを作ることが大切だと思います。

困ったこと

それほど深刻な問題にはなっていませんが、それなりに重いということはあげられると思います。

とはいえFW自体はそれなりに高速ですし、アクセスが集中した場合などはアプリケーションサーバーよりDBサーバーの方が悲鳴を上げるのは先なので、Symfonyだから問題というようなことはありません。

その他

参考までに開発スタイルなど適当に紹介します。

Routeは annotation で記述

ORM、Validator は yml で記述

Service も yml で記述

Translation の リソースファイルは php

DoctrineORM による Entity間のリレーションは使っていない

管理を容易にするため、設定ファイルは ./app/config → ./config に変更

アプリごとにドメインを変えるため、web/{app_name}/app.php という構成

まとめ

クロコスではSymfoy2を使って開発していますが、わりとスタンダードな開発を行っています。

サードパーティ製のバンドルはあまり使用せず、自分たちで作っていることが多いです。

ある程度のルールを持って開発しているので、無理なく開発を行うことができています。

FWがネックで困ったことはあまりありません。

以上、簡単なご紹介ではありましたが、また紹介する機会があれば書きたいと思います。

[crocos]

RDSのSnapshotミラー&テストツール [RDS TestRunner] をGoで実装した話

こんにちは @yudoufuです。

前回、Crocosにおける開発フローとテスト環境という記事を書いたら、いつの間にかBOTさんも進化しまして

。。。(　ﾟдﾟ) まぁこんな楽しい会社です。ということで、早速2回めを書くことになりました。

RDS TestRunner(Go版)を公開

前回の記事中で、「RDS TestRunner」というクエリ実行テストツールを紹介したところ、気になるーという声をいくつかいただきました。

小さなShell Scriptなので公開する程でもないかと思っていたのですが、せっかく要望を頂いたので公開用にGoで再実装しました。

https://github.com/crocos/rds-testrunner

ShellScript版はそのまま公開するにはちょっと業務依存を消すのが面倒だった + 自分のGoの勉強を兼ねて作ってみました。

RDS TestRunnerの概要

RDS TestRunnerは、RDSの最新SnapshotからDBを複製し、それに対して各種クエリを実行し、完了までの時間を計測します。 利用可能なRDSのEngineは、MySQLのみです。

もう少し細かく言うと、以下の作業をします。

RDSの最新SnapshotからDBを複製する

インスタンス名は実行ユーザー名を元に自動で付与される

DB Warm up用のSQLを投入する

列挙したSQLクエリを投入、各クエリの実行時間を計測する

チャットに実行完了通知を送る

現在はHipChatのみ

DBの複製機能以外はOptionalです。また、複製したDBの一括破棄もできます。 Configやパラメータの指定などによってこれらの実行を制御します。

主な用途として、ALTER TABLEなど重いクエリを実際に本番ミラーに適用して計測することで、サービス停止の要不要・メンテナンスタイムとして確保すべき時間をある程度正確に見積もるために利用します。

また、クエリの投入・計測をせずに複製機能だけを利用して、ログDBへの大掛かりな集計クエリを流すといった用途にも便利です。

ここでは、基本的な利用方法を紹介します。 より詳しい使い方については、README.ja.mdに記載してあるので、そちらをご覧ください。

Install

バイナリをDownloadしてください。LinuxとMacのバイナリがあります。 適当にpathの通ったところにrds-testrunnerのバイナリを置けば利用できます。

設定

最低限必要な設定を/etc/rds-testrunner.confに用意します。

resource "default" { instance = "your-instance-identifier" region = "ap-northeast-1" user = "db-access-user" password = "db-user-password" } aws { key = "<AWS_ACCESS_KEY_ID>" secret = "<AWS_SECRET_ACCESS_KEY>" }

resourceディレクティブにはDBインスタンスの情報を記載します。defaultは必ず用意してください。

awsディレクティブにはCredential情報を記載します。 この項目を設定する代わりに、ENVにAWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEYをexportしておくか、IAM credentialを使える環境でも実行できます。

基本的な操作

DBの複製とクエリの計測

クエリの計測には、openコマンドを使い、-qでクエリを列挙したファイルを渡して実行します。 (クエリファイルは、現状では1行毎に評価・計測するようになっているので注意してください。)

rds-testrunner open -q test-query.sql

-qを省略すると、DBを起動するのみでクエリを実行せずに終了します。

DBの破棄

利用し終わったDB群をまとめて破棄します。

rds-testrunner close

最後に

RDS TestRunnerの使い方について簡単に紹介しました。 HipChatへの通知など、いくつか細かい機能はあるのですが、そちらはREADME.ja.mdをご覧ください

Goを使うのは初めてで、これを実装しつつ徐々に言語を理解していたので、Classによってコードの実装品質がばらついていたりします。。。 ぜひぜひ使ったり見てみたりして、ツッコミ/Pull Requestがいただけると嬉しいです。

[crocos]

Crocosにおける開発フローとテスト環境

みなさん初めまして、@yudoufu です。 クロコスのCTO室というところで、主にインフラ & ミドルウェア & 開発プラットフォームと社内システム的なことを担当してます。

最近筆不精なもので、入社以来「いつブログを書くんだ」というプレッシャーを周囲から受け続ていたたわけですが、1年と2ヶ月にしてついに

こんなものが登場し、日々botにせっつかれるように。。。ヽ(´Д`；)ﾉｱｩ... (see: http://qiita.com/sotarok/items/b3d6fc80407f8128af0d)

というわけで、心を決めてエンジニアブログを書くことにしました。

前置き

さて、自分からはCrocosのプラットフォームについてご紹介したいと思います。

全体的なインフラについては、@sotarokが以前 Crocos を支える技術 の中で概要を紹介していました。

もちろんアップデートも色々あるのですが、同じ紹介をしても面白く無いので、今回は少し視点を変えて開発・リリースフローやテスト環境などについて紹介したいと思います。

開発 〜 リリースに至るまでのフロー

クロコスの開発は、基本的には@sotarokが開発したgit dailyを利用したフローになっています。 ざっくりまとめると、以下の様な流れです。

開発時には、最新のdevelop ブランチからfeatureブランチを切る

リリースの目処がたったら、feature/xxxxxブランチ単位でdevelopブランチへのPull Request(以下、PR)を出す

PRに対してレビュアーがレビューを行い、OKがでたらdevelopにmergeする

クロコスでは、OKの際には:+1:を付けることになっています。

developへPR mergeが走ると、そこからreleaseブランチが作られ、staging -> production へと順次デプロイされる

最終的にリリースが完了した差分がmasterにmergeされる

Gitベースの開発フローが多く語られるようになった最近では、わりと一般的なフローになっていると思います。

PRレビューの際にはTrelloのGitHub連携を使っていて、誰がどれくらいレビューを持っていて、今どのPRがどういうステータスかを管理しています。

:+1:の付いたPRをdevelopにmergeすると、WebHook経由でリリースの概要通知と共に、自動デプロイが走ります。

このへんの自動デプロイ等については、機会があれば取り上げたいと思います。

2種類の継続テスト

CI用にJenkinsが動いていて、大きく2種類の継続テストが常時実行されています。

メインとなるdevelop/masterブランチに対するテスト

JenkinsのGit Pluginを使って、常に最新の状態をテストしています。 フローの中では、developにPRからのmergeが走った場合になりますが、機能的にはリリースと連動していません。

下記のPR単位のテストのお陰でFAILが少ないのと、だいたいproductionリリース前までにテスト結果が出るので、 問題がでたらリリースを一旦停止する、という対応を取っています。

各PullRequestごとのfeatureブランチに対するテスト

これにはGitHub PullRequest Builder Pluginを利用してテストしています。 個別のcommitに対して以下のようにチェックが走り、

これらが全て通ると、GitHubのmergeボタンにAll is wellとコメントが付いて、問題なくmerge出来ることがわかります。

テストが通っていないものは、基本的にレビューされません。 developにmergeされるものはテストが通っているもの、という保証がつくので、mergeする側としてもわりと気持ちが楽になります。

ちなみにこのPluginは、PR内のコメントをフックして特定のキーワードでテスト再実行する機能があり、クロコスのJenkinsは(おやじ|おじさん|おっさん)をキーワードにしています。

あ、ちなみにこのスクリーンショットはGitHub障害時のもので、普段は1回呼べば再実行されます。おっさんはちゃんと頑張ってますよ。

DBミラーを利用したクエリテスト

CI的なソースコードへのテスト以外にも、必要に応じてDBへのクエリテストも実施しています。

クロコスのサービスインフラは全てAWSに乗っていて、DBにもRDSのMySQLインスタンスを利用しています。

RDBMSでサービス運用を行っていれば、当然DBのschema変更が必要になってくるタイミングがあります。 また、直接DBに対してイレギュラーな調査クエリを投げる必要が出ることもあります。

ただ、大きなテーブルへの変更や大きめのクエリを使う場合などには、本番DBにいきなり実行すると長時間のロックが掛かったりしてサービスへ影響してしまう危険があります。とはいえテストDBだと規模感がつかめません。

そこでクロコスでは、本番DBのミラーDBをワンショットで作ってくれる RDS TestRunner というツールを作り、実行時間を計測して影響度を計測テストするようにしています。

RDS TestRunnerはシンプルなshellscriptで、RDSの最新のAutomated Snapshotを元にして本番のミラーを構築し、クエリを投入して実行時間を計測してくれます。

実行イメージとしては

% ./rds-testrunner.sh open -q <queryfile>

とすると、自動的にDBのミラーを作成してクエリを実行、時間を計測します。

これ自体の実行時間は、インスタンスの起動とrestore、InnoDBのWarmUpを行った上でクエリが実行されるのでそこそこ時間のかかるツールですが、完了するとHipChat上に通知するようにしているので、動作させたら後は放置できて便利です。

これによって本番への影響が数値として明確になるので、それを元にメンテの要不要、停止時間などを見積もってサービスへの影響が極力小さくなるように運用しています。

また、これをすることでクエリ自体も本番データでほぼ確実に成功する事がテストされるので、安心して本番適用できます。

おわりに

リリースフローと、その間に利用されるテストについて簡単に紹介しました。

ありきたりの話も多かったかもしれませんが、DBのクエリテストなどはRDSサマサマでものすごく実験コストが低く済み、クラウドの使い方としては良い仕組みかなと思っています。

まだまだ紹介できていないところもありますが、このくらいの話でも何かみなさんの参考になるところあれば、筆無精が頑張った甲斐があるので、ぜひぜひコメントなどいただければ幸いです＼(^o^)／

[crocos]

Crocosマーケティングのリニューアルを通じて一番重要なことに気づかされた話

こんにちは、はじめまして！デザイナーのchacoです。

先日、長らく手を入れていなかったCrocosマーケティングのサービスサイトをリニューアルしました！

https://marketing.crocos.jp/

リニューアルの結果、資料請求数が1.5倍になり、サイトの直帰率も改善しました。

具体的に何をしたか

実は、特別なことは何もしていません。

新しいコンテンツを頑張ってつくったわけでもなく、グラフィックにこだわったわけでもない。

誰のためのサイトなのかを考える

見出しを大きくて見やすくする

ユーザーが知りたいと思っていることを書く

などなど、普通のことをしただけです。

でも以前のサイトはそれが出来ていませんでした。 このサイトで「誰」が「何を」することが一番優先順位が高いのかを考えられていなかったし、見出しと他のテキストの区別がつきにくかったし、ユーザーが気になっていること、知りたいことよりも、私たちが言いたいことを言ってしまっていました。

今回リニューアルにあたり、そういった足りていなかったところをきちんと考えようという方向性でプロジェクトを進めました。 私たちにはHCD(ユーザー中心のデザインの方法で、UXデザインのベースになってるもの)/UXD(user experience design)のようなノウハウがなかったので、外部のUXD専門家の方々にお願いして、一緒にプロジェクトを進めることにしました。

誰のためのサイトか

ミーティングの時の会話で印象的だったのは、「これは誰が見るのですか？」ということです。

最初のミーティングでは、その「誰」を考えるだけで終わってしまったくらい、時間をかけて考えました。 今までだったらまず機能や画面構成を考えてしまっていたと思います。

その後は、「誰」が「何を」するサイトなのかというストーリーを考え、それに必要なものを必要な場所に配置していきました。 つまり、ユーザーにとって違和感がないように、必要なコンテンツを整理していくという作業を行いました。

でも、それこそがいちばん重要で、今まではそんな当たり前のことができていなかったのだと痛感しました。 以前のサイトに足りていなかったのは、サイトにおけるストーリーだったと思います。

一番重要なこと

「誰のため」のサービスなのか。 まずここから始めることは、Webだけではなく、どんなことにも言えると思います。

つくることに夢中になって、いつの間にかこのいちばん大切なことを忘れてしまわないように、これからもデザインを続けていきたいと思っています。

[crocos]

社内チャットの Skype + IRC という環境を撤廃して HipChat 一本にした話

こんにちは。久しぶりです。@sotarok です。 久しぶりにもほどがありますが、そしてエンジニアブログでこのネタというかんじですが、まあ良いとして、今日はそんな話をします。

弊社では、これまで

Skype (非エンジニア・全社的やりとり)

IRC (エンジニア)

でやっていたのですが、ココ最近これを HipChat に移行し、一本化しました。 HipChat は Confluence などで知られる Atlassian 社の運営するチャットツールです (2012年に買収したらしい)。以前は月額 $2/user から始められる小規模な人数の会社等ではコスト的にもバランス感の調度良いツールでしたが、最近無料になりましたので、ますます薦めやすくなりました。(ちなみに弊社では検索ログ保持のため $2 で使っております。

昨年末くらいからテスト導入を始め、1月末に本格移行、それから半年ほどが経過し、運用もこなれてきました。 実は2月くらいに「それから1ヶ月ほど経過し」と書き、4月頃に「それから3ヶ月ほど経過し」と書き、ずっと下書き状態だったブログですが、ようやく公開しますw

ということで、今日は、移行の際に検討した内容などを元にチャットツールとは本質的になにが満たされるべきかを考えたいと思います。

Skype と IRC、そしてそれらを併用することの問題点

そもそもなぜ Skype と IRC を使っていたのか、統合・移行しようと思ったかというと、エンジニア・非エンジニアどちらもそれなりに人数が増えてきて (それぞれ15人くらい...半々程度)、ツールの分断があることが、結構面倒になってきたところが主な理由です。 Skype、IRC にそれぞれ部屋が増えてきて、どこのツールのどこの部屋でしていた会話だかわからなくなることが多々ありました。

そもそも Skype と IRC を使っていたワケ

Skype には、

1on1 チャットがある

グループ会話ができる

だいたいみんなアカウントを持っていて導入が簡単だった

また、過去の経緯で、クロコスは設立当初リモートで Skype 通話で会議したりしていた

IRC は開発者全員もともと使っており、

色んな物を通知してくれて、

bot も簡単に導入できて、

使い慣れていた

そんなこんなで創業当初から、開発IRC、それ以外Skype という構成でやっていました。

IRC、Skype それぞれの、問題

…という、導入しやすさがそもそもあったのは事実ですが、皆さんご存知の通り、この2ツールにはそれぞれ色々面倒な問題がありますよね？ありますよね？

Skype

P2P には限界がある

メッセージ送ったのに届かないことがある

複数マシンでログインしっぱなしだと時々メッセージが消失する

モバイルアプリがダメすぎる

個人アカウントの問題

なんかイケてない (えっ

IRC

正直開発者以外には微妙

プロクシ立てたり

アカウント管理が曖昧 (社内アカウント管理とプロクシのために znc 使っていました)

複数行とか ... まあ細かいことはいいや

ま、それぞれ、挙げたらキリがないんですが。

チャットツールとしての本質的要件

そんなわけで、乗り換えを検討していたのですが、僕がどんな視点でツールを選んでいたかちょっと書き出してみます。 まず、チャットツールとしての本質的な要件は何か、を考えます。

本質的には、

普段は非同期コミュニケーションとして流れる

見たいときに見る

返信できるときに返信する

見て欲しいものは流しておく

同期的コミュニケーションをとりたいときには同期的なコミュニケーションが取れる

呼び出したい人を簡単なUIで呼び出すことができる

呼び出された人はオンライン・オフラインにかかわらず気づくことができる

すごく抽象的になりますが、必達要件はこの2点で、これを実現するためにいかにバランスのよいUIや通知系統を兼ね揃えているか、が重要なポイントになります。

それをブレイクダウンした必須要件

以上の問題点、要件から出された必須要件としては、

専用クライアントがあること (ブラウザベースではない)

ブラウザは他の仕事でも利用しタブも埋もれる、通知系統が未成熟、ブラウザ内におけるキーバインドの限界などからNG

通知系統のOSとの統合が必須

OSの通知機能などと統合された通知ができ、人または任意のキーワードで通知ができること

Mac であれば Notification Center

Windows ではOS標準の機能ではないものの、たいてい右下からポコンと出てくるタイプのやつ

非同期かつ、必要に応じて同期的コミュニケーションができることとして、呼び出しができることは必須

不在時でもメッセージが到達し、通知ができ、ログがさかのぼれること

到達されないのは論外

botによる通知ができること、各種ツール (社内ツール、GitHub、Jenkinsなど) との連携が可能なこと

開発者が使うには絶対に必要

各種ツールと統合できるには必須

の4点です。 これ以外の要件は "必須ではない" ものとし、しかしできればの要件としては以下のようなものをあげておきました。

過去ログの検索

モバイルアプリの有無

使い慣れたデータモデル (部屋を作成 → その中でその話題をする)

HipChat

上記要件を満たせるものとして検討したものを挙げます。評価軸は上記必達要件がどの程度満たせるか、です。(昨年末時点での検討なので、サービスの状況はこの半年で変わっているので今評価すると色々違うかもしれません。)

ChatWork

HipChat

Slack

ま、その他いくつかも検討しましたが、要件を満たすものとして HipChat を試してみることに決めました。

HipChat の良いところ

要件を満たしている、ということは最低条件として、特筆すべきところは、こんなかんじです。

通知系統が優秀 (これが決め手)

名前のコールでポップアップ通知 (Mac なら Dock ではねてくれる)

オフラインのときに名前通知が来るとメールでも通知くれる (さらに、前後の会話がメールに含まれるので文脈もわかりやすい)

iPhone アプリも使いやすかった (まあ、というか普通?)

海外ですでにある程度名前が売れていたおかげで、各種ツールからの連携がしやすかった (GitHub の Hook 設定でもデフォルト準備されている、など)

bot も作りやすかった!

ま、ざっくり言うとこんなもんでしょうか。

導入試験〜導入

まず、実際の使い勝手を知らないと全社に展開しづらいので、主にリーダー陣の使うチャットで、ひと通りの機能や使い勝手を試す期間を2週間ほど置きました。 (ちなみに導入試験中は、リーダー陣は、Skype IRC HipChat の3つを使う必要があり、完全にカオスでした ...)

リーダー陣を先にこういう試みに巻き込むことは、その後のメンバーへの展開で各リーダーが自分の言葉で語れるようになるので良い方法かと思います。

実際導入にあたっては、ドキュメントの整備と、説明会を開催しました。

全社でコミュニケーションツールが一本化された

ツールが分断していることは、組織に想像以上に大きな悪影響を与えます。

それは「コミュニケーションが分断される」ということです。

コミュニケーションが分断されて良いことは何も起こりません。ツールは所詮ツールなので、円滑なコミュニケーション促進には、ツールの統一だけで「十分」にはなりませんが「必要」である、とは思います。 「誰々に連絡をとりたいけどあの人XX使ってないから連絡とれないんですよね」によって損なわれるコミュニケーション機会は非常にもったいないんですよね。

導入前後では、エンジニア <-> 非エンジニア のコミュニケーションが以前に比べて自然とできるようになったと感じます。

通知系統が一本化された

これは特に開発者向けのメリットですが、IRC で bot からの通知を受けたり、Skype で人から呼ばれたり、というわけのわからなさw がなくなり、常に HipChat からの通知が来るようになりました。

今は、GitHub のレビュー状態や、デプロイの情報を bot に通知させているので、基本的に HipChat の通知を気にすれば重要な情報は通知される、という状況を作っています。

たとえば、うちだと PR に +1 で出るとマージして良いのですが、こんなかんじで通知してくれます。

あとは、デプロイ時に、関係ある人 (そのデプロイに含まれる人) にも通知してくれたり

逆に HipChat のイケてないところ

ま、それもそれなりにあるわけで、一応書いておきます。

任意の通知キーワードを設定できない (名前 here all のみ)

アバター表示がない、Nickname 表示がない (本名表示のみ)

組織によっては、英語ツール、というのが気になることはあるかも

Windows Client がだいぶイケてない ...。

リンクがクリッカブルじゃない (これが致命的すぎて一部の人は Chrome の切り出す機能を使ってアプリっぽく使ったりしている)

Mac 版ではあるのに (そして便利なのに) ...

名前クリックで mention とか できない

Show divider for unread message の設定がない

そういうわけで

ツールとして何を採用するかは、その組織やチームの状況、ステージによって違うと思うのですが、なんでもいいけど大部分の要望を満たせるツールの導入のために本質的要件を考えるのは非常に重要だよ、というお話でした。

今や当たり前のようにオンライン上でコミュニケーションを取りながら仕事をしていきますが、日々環境や組織の状況は移り変わるので、不便が積み重なる前にツールの整理をしておくクセはつけたいな、と思います。

これをお読みの皆様も何かのヒントにしてみてくださいね！

Let's Happy Chatting!

[crocos]

jquery-tutor というプラグインを作りました

おひさしぶりです。riaf です！

今日は、ちょっとした jQuery Plugin を作ってみたのでその紹介です。 ちなみに、まだ Crocos のサービスには使用していないので、ちゃんといろんな環境で動くかどうかはわかりません..。 おかしなところがあったらぜひぜひ Pull Request をおねがいしますね！（見た目をかっこ良くしてくれたりとかも大歓迎です！）

何をするプラグインか

サンプル を見ていただければイッパツなんですが、 ウェブサービスのチュートリアルを、そのサイトを実際に見ながら進めるやつ、あるじゃないですか。

あれがそこそこ汎用的になってるとやりやすいなーと思って作ってみました。 Crocos には Hack Hour という制度があり、先週末の Hack Hour で気分が高まって作ってみた、というレベルの状態ですので、今後ちゃんとプロダクション環境で使えるようにして行きたいと考えています！Hack Hour については、後ほど紹介します。

使い方

jquery-tutor.min.js を読み込んだら

$(function() { $.tutor({ steps: [ { target: '.step-one', message: 'まずは、ここから' }, { target: '.step-two', message: '次は、ここ。' } ] }); });

のようにして、操作の対象になる element を target に指定して、表示するメッセージを設定します。 Next ボタンを押したら次のステップに移動します。

steps に指定できるのは element を指定した object だけではなく、何かする function を指定することもできます。 Deferred Object を return すると、resolve されるまで次のステップは実行されません。

$(function() { $.tutor({ steps: [ function() { alert('Welcome!'); }, function(dfd) { // async FB.api('/me', function(me) { alert(me.name + 'さんですねー！'); dfd.resolve(); }); return dfd.promise(); } ] }); });

ダウンロードなど

GitHub で公開しておりますので、煮るなり焼くなり...！

crocos/jquery-tutor · GitHub

https://github.com/crocos/jquery-tutor

Hack Hour について

毎週金曜日の 2 時間、仕事とは関係がない（もちろん、関係があっても OK。というか、技術的なことならだいたい関係してきますよね）技術の勉強とか、開発とか（たとえば、社内で使っている wiki システムの新機能開発とか）をする時間が設けられています。 わりと最近はみんな忙しくて参加率低めなんですが、ゆるゆると「今日はこんなことやろうかな！」と宣言して終わる頃に「ここまでやったよ！」みたいな共有をして終わります。

この Hack Hour で仕込んでいるネタもいろいろあるので、今後もブログとかで報告していけるといいなーと思ってます。

[crocos]

Facebook Night vol.9でオープングラフについて発表しました

みなさんこんにちは。小川[@fivestr](https://twitter.com/fivestr)です。 8/28に行われた[Facebook Night vol.9](http://fb.dev-plus.jp/event/facebook-night-vol9/)で、オープングラフについて発表してきました。その資料をアップしましたのでご紹介します。 今回は「オープングラフを導入しよう」というタイトルで、これからオープングラフをアプリに導入していきたい方を対象に、オープングラフとはなにか、どのようにしてアプリに導入していくかを解説しています。実際にクロコスでは、[Crocosいいねクーポン](http://marketing.crocos.jp/apps/coupon)や[Crocosコンテスト](http://marketing.crocos.jp/apps/contest)といったアプリでオープングラフを導入しており、導入時の実体験に基づいたアドバイスなんかも書いてあります。 オープングラフについてはブログで紹介しようと思いつつずっと書けないでいたのですが、ひとまず大まかな流れはスライドを見てもらうとして、細かい部分などを今後ブログに書いていければなーと考えています。 ### 会社のこと スライドの中にも書いてありますが、[クロコスはヤフー株式会社の完全子会社になりました](http://crocos.co.jp/news/2012/08/crocos-yahoo/)。びっくりですね。 先週からミッドタウンにオフィスを移転して、ヤフーの方と色々お話ししてるんですけど、本当にいい会社です。ここ数日テンション上がりっぱなしです。色々とああしたいこうしたいという意見が飛び交っていますので、どんどんそういうのを実現化して、ヤフーとクロコスすげー！ってなるように一同がんばります！

[crocos]

Titanium と alloy ではじめるスマートフォンアプリ開発

連日のブログ更新に触発されて今日も書いちゃいます、Crocos の人柱担当、佐藤 (@riaf) です。

というわけで、本日は iPhone アプリとか Android アプリとかを JavaScript で開発できちゃうっていうステキなプロダクト Titanium Mobile のお話です。Crocos ブログのくせに、 Facebook の話題はまったくありません！

いずれは Facebook と連携するアプリの開発方法とかをご紹介できればとおもいますが、まずはまだあまり日本語の情報がない alloy についてのご紹介です！

alloy とは？

Titanium Mobile の開発元である appcelerator が GitHub で公開している、Titanium 向けの MVC フレームワークです。

この記事を書いている 2012年 7月現在は、Unstable バージョン（日本語にすると一般的には不安定バージョンとでも言うんでしょうか）の状態ですので、Stable リリースの頃にはまた違うものになっているかもしれませんが、人柱担当としては手を出しておくべきかと思いまして、alloy を使って iPhone アプリを作ってみようと思います。

https://github.com/appcelerator/alloy

アプリ開発を始める

alloy は Titanium 向けのフレームワークですので、まずは Titanium SDK が必要になります。

今回は Mac で開発をしたので、Titanium Studio の Mac 版をダウンロードしました。

早速起動してプロジェクトを作ってみます。iOS アプリを作るときは iOS の SDK が、Android アプリを作るときは Android の SDK のセットアップが必要です。このへんは巷に導入方法がたくさんありますので、そちらにお任せして、今回は crocos というアプリを作成してみました。

割と適当にこんなかんじに作成してみました。そうすると、最低限なコードが作られています。

$ ls CHANGELOG.txt LICENSE LICENSE.txt README Resources build manifest tiapp.xml

これで、Titanium の準備は完了です。

alloy をインストールする

alloy は npm で配布されているので、node を動作させる環境を作っておくと良いでしょう。僕は、nodebrewというツールで node や npm を管理しています。とても便利なので、オススメです！

さて、alloy のインストールは

npm -g install alloy

とするだけです。これで、 alloy コマンドが使えるようになります。

$ which alloy /Users/riaf/.nodebrew/current/bin/alloy

alloy をセットアップする

それでは、先ほど作成した Titanium プロジェクトのディレクトリに移動し、alloy をセットアップします。

# もちろん、環境によって読み替えて下さい。 $ cd ~/Documents/Titanium_Studio_Workspace/crocos $ alloy new .

alloy のセットアップは alloy new するだけです。

# 上の続きです $ alloy new . .__ .__ _____ | | | | ____ ___.__. \__ \ | | | | / _ < | | / __ \| |_| |_( <_> )___ | (____ /____/____/\____// ____| \/ \/ Alloy by Appcelerator. The MVC app framework for Titanium. 2012-07-11 23:44:20 -- [DEBUG] Creating directory: plugins 2012-07-11 23:44:20 -- [DEBUG] Creating directory: plugins/ti.alloy 2012-07-11 23:44:20 -- [INFO ] Deployed ti.alloy plugin to plugins/ti.alloy/plugin.py 2012-07-11 23:44:20 -- [INFO ] Installed 'ti.alloy' plugin to tiapp.xml 2012-07-11 23:44:20 -- [INFO ] Generated new project at: app

Generate できました。

ここで、とりあえず iOS シミュレーターで実行させてみようと思います。が、nodebrew 等を使っている環境でそのまま実行 (Mac の場合は F11 にショートカットがあるようです)しようとすると、OSError: [Errno 2] No such file or directory と言われてしまって、実行することができません。

これは、plugins/ti.alloy/plugin.py に記述されている node や alloy のパスが /usr/local/bin で決め打ちされてしまっているためなので、対象の行を修正する必要があります。

具体的には以下のように書かれているところを、実際に node や alloy が存在するパスに書き換えてやります。 (現在は 27 行目付近)

cmd = ["/usr/local/bin/node","/usr/local/bin/alloy", "compile", f, "--no-colors", "--config", cfg]

修正した後にもう一度ビルドすると、以下の様な画面を見ることができます。テキストをクリック(タップ)すると、アラートが表示されるだけのサンプルです。

alloy のディレクトリ構成

alloy では、基本的に app ディレクトリの中を編集します。

主に以下のファイルを読むと構造がわかると思います。

app/controllers/index.js

コントローラ。テキストがクリックされたときにアラートを発生させるコードが書かれています。

$.t.on('click',function(e) { alert($.t.text); }); $.index.open();

app/styles/index.json

スタイル。CSS のように、見た目に関するデータ(色や、サイズなど)が書かれています。

{ ".container": { "backgroundColor":"white" }, "Label": { "width": Ti.UI.SIZE, "height": Ti.UI.SIZE, "color": "#000" } }

app/views/index.xml

ビュー。HTML のように、実際に配置する要素が書かれています。

<Window class="container"> <Label id="t">Hello, World</Label> </Window>

このサンプルではモデルは使われていないので、MVC の分離という意味では物足りないかもしれませんが、このように、 alloy ではウェブアプリケーションを開発したことがある人には馴染みのあるようなファイル構成で、スマートフォンアプリを開発することが出来るようになります。

とはいえ、まだまだ開発中っぽくて、どんどんコミットされているプロジェクトですので、業務での活用は難しいかもしれませんが、今後はこういった流れもあるかもと思っていると、心の余裕ができて良いですよね！

ぼくは、まず休日にでも、お遊びでアプリ開発してみようと思います！進捗があったらまたブログに書こうと思いますのでお楽しみに...！(Facebook 連携まで進めるだろうか...)

[crocos]

Facebook PHP SDK 解体新書 第5回「JavaScript SDK と連携してる際に適切に Access Token が取得できない問題について」

こんにちは。 @sotarok です。 Facebook PHP SDK について深〜い解説をする「解体新書」シリーズ、今日はじめて書くんですがいきなり第5回から行ってみようと思います。

というわけで、表題の通り、「JavaScript SDK と連携してる際に適切に Access Token が取得できない問題について」のお話をします。

※ ちなみに執筆次点でリリースされている Facebook PHP SDK v.3.1.1 をベースとしています。

補足の前提知識、JavaScript SDK と PHP SDK の連携

Facebook PHP SDK は、JavaScript SDK と、特に何も意識せずに COOKIE を介して連携しています。具体的には、JS で FB.init() された際に生成される fbsr_xxxxx という COOKIE を PHP SDK が読み取り、その情報 (Signed Request 相当のデータが格納されています) を元に PHP SDK 上でもログインすることができるようになっています。

突然発生しはじめたエラー

Facebook ではよくあることですが、今まで動いていたコードが、APIサーバー側に施された何かによって動かなくなると言うことがあります。 で、今日出会ったのは、

$facebook->getAccessToken();

が動かない！という問題です。特に認証周り何もいじっていないのに、次のような OAuthException が発生するようになりました。

This authorization code has expired.

しかも、

人によって発生したりしなかったり

アプリによって発生したりしなかったり

という状況で、やれやれな雰囲気が出ています。わかったからこそこういうタイトルで記事を書いていますが、JavaScript SDK と連携していたせいで発生していたエラーだということに気づいたのはほとんど解決する直前でした。

このエラーは、 getAccessToken() を呼んだ際に発生していたのですが、それを発見するに至った経緯も含め、を詳しく見ていくことにします。

コールされたAPIとその結果

開発環境で再現条件を探るなかで、手順を最小限にするため、次のような画面遷移のみに絞って検証をしました。

PHP SDK の getLoginUrl() メソッドで取得できる URL にジャンプ (ご存じの通り、飛び先は Facebook の認証画面)

戻ってきたページで getAccessToken() メソッドで Access Token を取得

つまり、HTTPリクエスト的には、

うちのアプリでログイン用URLの生成

Facebookの認証画面

うちのアプリに code パラメータ付きで戻ってくる。それを元に Access Token を取得

という遷移をします。一応弊社のライブラリでは、Facebook PHP SDK がリクエスト飛ばす部分に手をいれて、

どんなリクエストが飛んで、

どんな結果が返ってきているのか、

がすべてログに出せるようになっています。このとき発生したログは、「2.」のタイミングで、

[2012-07-10 17:26:42] app.DEBUG: Facebook API[1]: https://graph.facebook.com/oauth/access_token - {"client_id":"10472078961xxxx","client_secret":"daa8a082d4db023bf1316f2e49dfxxxx","redirect_uri":"","code":"2.AQCOriuA5Anxxxxx.3600.1341910800.1-58888xxxx|1341905535|iOoQHNn-ZPesX6RsXBwUCibxxxx"} (10472078961xxxx|daa8a082d4db023bf1316f2e49dxxxxx) [] [] [2012-07-10 17:26:43] app.DEBUG: Facebook API[1] result: {"error":{"message":"This authorization code has expired.","type":"OAuthException","code":100}} [] []

というログが出ていました。このとき、Facebookからどいういうパラメータ付きで戻ってきたかというと、正常に認証が完了し、 /login/check?state=xxxxxxxxx&code=XXXXXXXXXXXXX のように、CSRFチェック用tokenであるstate (今回は詳しくは言及しません) と Access Token 取得のための code を query string に付与して戻ってきていました。 で、その画面で、/oauth/access_token に code をつけてリクエストを送ったタイミングで、OAuthException の "This authorization code has expired." が発生した、ということです。

最小の手順でこれが発生するということは、もう getAccessToken() が怪しくてしかたありません。ということで、このメソッドの中身を見ていきます。

getAccessToken() がやること

このメソッドは、

public function getAccessToken() { if ($this->accessToken !== null) { return $this->accessToken; } $this->setAccessToken($this->getApplicationAccessToken()); $user_access_token = $this->getUserAccessToken(); if ($user_access_token) { $this->setAccessToken($user_access_token); } return $this->accessToken; }

こういうメソッドで、つまり、

$this->access_token がセットされていたらそいつを返す

デフォルト値としてとりあえず Application Access Token をセットする

これは、 APP_ID と APP_SECRET をパイプ | でつないだものです

User Access Token を取得できたら、そいつをセットする

で、この中で怪しいのは、というか、/oauth/access_token にリクエストを飛ばすのは、明らかに getUserAccessToken() です。

getUserAccessToken() がやること

メソッドは、次のようになっています。

protected function getUserAccessToken() { // first, consider a signed request if it's supplied. // if there is a signed request, then it alone determines // the access token. $signed_request = $this->getSignedRequest(); if ($signed_request) { // apps.facebook.com hands the access_token in the signed_request if (array_key_exists('oauth_token', $signed_request)) { $access_token = $signed_request['oauth_token']; $this->setPersistentData('access_token', $access_token); return $access_token; } // the JS SDK puts a code in with the redirect_uri of '' if (array_key_exists('code', $signed_request)) { $code = $signed_request['code']; $access_token = $this->getAccessTokenFromCode($code, ''); if ($access_token) { $this->setPersistentData('code', $code); $this->setPersistentData('access_token', $access_token); return $access_token; } } // signed request states there's no access token, so anything // stored should be cleared. $this->clearAllPersistentData(); return false; // respect the signed request's data, even // if there's an authorization code or something else } $code = $this->getCode(); if ($code && $code != $this->getPersistentData('code')) { $access_token = $this->getAccessTokenFromCode($code); if ($access_token) { $this->setPersistentData('code', $code); $this->setPersistentData('access_token', $access_token); return $access_token; } // code was bogus, so everything based on it should be invalidated. $this->clearAllPersistentData(); return false; } // as a fallback, just return whatever is in the persistent // store, knowing nothing explicit (signed request, authorization // code, etc.) was present to shadow it (or we saw a code in $_REQUEST, // but it's the same as what's in the persistent store) return $this->getPersistentData('access_token'); }

コード中のコメントが解説してくれていますが、今回画面遷移の場合とあわせて解説すると、

Signed Request があったらそれを使って access token をとりにいくよ

Signed Request は、Facebook App Canvas や Page App の Canvas で開いたとき、iframe ごしにくるリクエストなので、今回のような、App Canvas 内ではない場所で利用しているアプリでは基本的に関係ない（はずである）

そうじゃなかったら code を使って、Access Token を取得しにいくよ

今回の場合、Facebookの認証画面から code 付きで戻ってくるので、こっちでリクエストが飛ぶはずである

Signed Request もなくて、code もなかったら、一応最後に、Persistent Data (セッションです) に入ってる access token を返すよ

今回はここにはこないはず

という処理になっています。

エラーメッセージが「This authorization code has expired.」なので、/oauth/access_token に対して Access Token の発行のリクエストを飛ばすタイミングでつけている code が expire してるぜってことっぽいので、まず、どんな code を使ってるのかを確認します。 こういう場合は当然必殺の「var_dump()とexit」なので、次のように、code を出力してみます。

$code = $this->getCode(); var_dump($code);exit;

この状態で、同じ遷移をテストすると ...

お ... code が出力されない！

あれ、code のところに来てない？ってことは signed_request に何か入ってるんだっけ？という疑いのもと、以下のようにデバッグコードを仕込むと ...

$signed_request = $this->getSignedRequest(); error_log(var_export($signed_request, true));

ログには ...

[10-Jul-2012 08:31:36 UTC] array ( 'algorithm' => 'HMAC-SHA256', 'code' => '2.AQCOriuA5Anxxxxx.3600.1341910800.1-58888xxxx|1341905535|iOoQHNn-ZPesX6RsXBwUCibxxxx', 'issued_at' => '1341909094', 'user_id' => '58888xxxx', )

見事に、入っていました。このときハッとしたのですが、これは、JavaScript SDK によって入れられたものです。 getSignedRequest() の中身は今回は紹介しませんが、大まかにいうと、POST リクエストで Signed Request のデータが渡されていればそれを、それがなければ COOKIE から復元という手順で Signed Request を返してきているからです。

つまり、認証手順で Facebook から code が返されているにもかかわらず、それを使わず、それより古くにJSで設定された Signed Request 内の code を使って access token をとりにいくから expire してました 、という話でした！ これを無視して、クエリで渡された code を使って認証すれば、正常に Access Token を取得することができました。

人によって・アプリによって発生したりしなかったりしたのは、その人の COOKIE にそのアプリのデータが残っていたかどうかによるからですね。

問題の概要

今日突然起こるようになったことに対する想像

今までは、code に対する expire のチェックをしていなかったのではないか

つまり、JavaScript SDK によって COOKIE につっこまれた古い code を元に Access Token の発行ができた

これじゃまずいよね、とおもった中の人がついに expire のチェックをするようになった

しかし、このように、

query string などに code を受け取っていても、Signed Request があったらそれを最優先で認証に使う

Signed Request は JavaScript SDK によってセットされる可能性がある

code は expire する

という仕様になっているのであれば、「Signed Request を元に Access Token を取りに行く」というのは、必要だとして、正規の認証経路で戻ってきて code が query string に渡されていて、かつ、JavaScript SDK によって COOKIE に Signed Request がセットされている、という場合が存在するので、 Signed Request を元に access token を取得しにいって、だめなら query string に渡された code を元に Access Token をとりにいくという fallback 処理があるべきなのではないか、という感じです。 Signed Request が Signed Request によるものなのか、JavaScript SDKによるものなのか区別されていないので。

ところで、この問題は、以下の条件下で発生します。

どこかでそのアプリが FB.init されたことがあり、その時点から一定時間が経過している (expire する程度には)

getLoginUrl() がコールされて Facebook にジャンプする前に FB.init() される場所が無く、COOKIE も生きている

この条件を満たさない場合は回避できるでしょう。(たとえば、getLoginUrl() のURLにジャンプする直前の画面で JS で FB.init() されているとか)

ちなみに、Authorization Request の code に関しては、OAuth 2.0 の最新の proposal には、以下のような記述があります。

4.1.2. Authorization Response

code REQUIRED. The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once.

code の lifetime は最大でも 10 分が望ましい

client は、authorization code は1回しかつかっちゃだめ

このあたりを、ちゃんとチェックするようになったんですかね(いままでやってなかった...?)。

対策

対策としては、

FB.init() する画面を挟む

認証のリクエスト前に COOKIE 消す

getUserAccessToken() に Signed Request → code の fallback 処理を入れる

といったものが考えられますが、今回はアプリの画面遷移の特性上、COOKIE 消すことにしました。というか、destroySession() メソッドを呼ぶことにします。

本来、COOKIE が PHP にとって Persistent Data に近い存在として扱われるので、clearAllPersistentData() のタイミングで COOKIE を消すべきなんじゃないかなーと思っていますが、後日このへんのアイデアをまとめて SDK の修正案を Pull Request でもしてみようと思います。 ブログ書いてたら疲れたのでまた後日 ...

まとめ

JS SDK と連携してると、COOKIE で意外とハマる

突然エラーになったりする

まぁだいたいコードに書いてあるので1つずつ追えば原因はわかる

では、第1〜4回と6回以降もご期待ください。 次回は「JS SDK と連携している際にユーザの切り替わりを検知できない問題について」をお届けする予定です。

[crocos]

Treasure Data でモテモテ

はじめまして。 Crocosの平均年齢引き上げ担当の @cocoitiban こと新井です。 最近、結婚いたしましたので、一つ前の記事を参考に、妻に旧姓表示を教えたいと思います。

さて、以前弊社 CTO の sotarok の記事で、Crocos の技術基盤について説明があったとおもいますが、ちょっと深く掘り下げてご紹介したいと思います。 まずは、僕が入社して一番インパクトがあった Treasure Data について説明したいと思います。

どんなものか

sotarok の Crocos を支える技術でも紹介されていますが改めて紹介すると、大量のデータ解析ができるPaaSのサービスです。

fluentdと一瞬で組み合わせて使える

HiveQLでクエリを実行できる

データもTreasure Data側に保持しておける（こちら今サイトみると500GBまでは気にしないでいいみたいですね）

弊社では主にアクセスログの解析で利用しています。PHPのアプリ上で各種ログデータを生成して送信していますが、Apacheのログ等も簡単に変換して登録することが可能です。

ざっくりとですが、用語について説明します。

fluentd

fluentd ログ転送デーモンで、Scribeとかそういったのもそれなり有名なのではないでしょうか。 CPU負荷やネットワークトラフィックもWebサーバに入れている限りは考慮しなくていいレベルで、今のところCrocosで使っている限りは安定しているようです。

プラグインでいろいろできますので、たとえば、AmazonDynamoDB に送信するといったことも非常に簡単にできます。

Hive

目のいっちゃってるぞうさんでお馴染みの Hadoop でデータ解析をするための SQL ライクな構文をが使える命令群です。使っていて、基本的にSQLがわかるエンジニアならコツがわかれば、半日くらいで使いこなせた気分になります。

大量データを、「え？本当に」って速度で処理してくれます。 ところでどうでもいいのですが、Hive になるとさらにぞうさんいっちゃってますね。

そんなわけで、実はこの Treasure Data、実はもうすでに使えるようです。 もし私が Crocos のエンジニアではなくて個人でサイトをつくっていても、使ってみようと思えますしなにより、30分くらいあればその凄さを体感できますので、ぜひ試していただきたいです。

というわけで、少しチュートリアルにそった使い方を説明していきたいとおもいます。

導入方法

Treasure Data の Quickstart Guideに沿って進めたいとおもいます。

アカウントの新規作成

Sign Upページより登録します。

2012/07/12現在は、Quickstart Guide のリンクは間違ってるみたいです。

ちなみにここで書いたパスワード忘れないように注意してください。 しばらくすると登録メールが届きますので、指示にしたがって登録をしてください。

インストール

指示にしたがってインストールしてください。 手元の環境のMacでは何もはまるところなくパッケージでインストールできました。

そうするとtdコマンドが利用できるようになります。 その後、 アカウント認証をします。 ここらへんは、先ほどのQuickStartの指示そのままで問題ありません。

td account -f

でメールアドレスとパスワードを聞かれますのでそれを入力してください。

データベースの新規作成

これまた、QuickStartそのままで問題ありません。

td db:create testdb

td table:create testdb www_access

実際に使ってみる

これもまた。QuickStartの内容そのままで問題ありません。 親切なマニュアルがあるので楽ですね！ まずデータ登録をします。

$ td sample:apache apache.json

$ td table:import testdb www_access --json apache.json

$ tail -n 1 apache.json

なんと、tdコマンドにはテスト用のjsonを作成するようなそんな機能があります。 データが登録できたらクエリを実行します。

$ td query -w -d testdb \

"SELECT v['code'], COUNT(1) FROM www_access GROUP BY v['code']"

JSONの中身はそれぞれ、vという変数の中に入っていて、v['hoge']という感じで項目名を指定します。

しばらくすると値が返ってきます。簡単ですね！！

HiveのクエリはHive Tutorialを参考にするととっつきやすいです。

駆け足ですが、おそらく、一回触ってみるとなんとなくコツがつかめると思います。

よく使う機能

@Result Outputという機能が結構面白いです。

クエリを実行した結果を、自分たちで構築したデータベースに登録してくれる機能です。 自分たちで用意した場合バッチサーバを用意して、そこから、クエリの結果をデータベースに登録することになるので、サーバ一台用意しなくていい分非常に簡単です。

いくらTreasure Dataが高速とはいえ、ユーザに直接触れるところにおくのはレスポンス的には問題がありますのでいったん、自分たちのデータベースに格納してからユーザに表示するということは良いことです。

終わりに

これ、ある程度大きい会社だと結構似たような技術を利用できるのですが、個人で構築するのは結構大変なんじゃないかと思います。

それがこんなに簡単に利用できるようになるとは思いませんでした。

こういったものを使ったことがあるというのはそれはそれでひとつのスキルといえると思いますし、一般的な技術を使っていますので、いろいろ問題を解決しやすいというメリットもあると思います。

次回は、Webアプリケーションから Fluent を経由しログを投げる方法や、Crocos内部にてどのように使っているかを簡単に説明したいと思います。 本記事がご参考になれば幸いです。

[crocos]

Crocosスケジューラの裏側

こんにちは！Crocosのエンジニア兼お問い合わせ担当の@yuchimiriです。

最近Facebookで地元の同級生とかをたくさん見かけるようになったのですが、結婚した友達の苗字が変わったりしていると、友だち申請が来てもしばらく誰なのか気付けなかったりします。

既婚者の皆さん（主に女性）は、プロフィールに旧姓を登録しておくと、気づいてもらいやすくていいですね！

nanapi: 「Facebook」で旧姓と現姓の両方を表示する3つの方法

ちなみに私はまだ使う予定がありません。

さて今回は、2011年の春にCrocosとして初めてリリースしたFacebookアプリであるCrocosスケジューラを例に、FacebookAPIを使ってFacebookイベントを作る方法とそのTipsについてご紹介します。

Crocosスケジューラとは

Facebookの友達同士で、イベントの日程調整を行うためのアプリケーションです。

開発当初はFacebookアプリについてまったくの初心者の状態だったので、実はこのアプリ自体は練習的な意味合いを込めて作ったのですが、今では多くの人に使っていただいていて、本当に嬉しい限りです。ありがとうございます！

というわけで、まだアプリを使ったことのない方もいらっしゃると思うので、まずはCrocosスケジューラを使う際の大まかな手順についてご説明します。

Crocosスケジューラ上で日程調整ページを作成する

参加して欲しい人にイベントの招待（アプリリクエストまたはメール）を送る

招待された人は、日程調整ページから候補日の予定を回答する

イベント作成者は、回答を見て人数の集まりそうな日程でCrocosスケジューラ上からFacebookイベントの作成を行う

わぁ、簡単ですね。

他にもいくつか細かい機能はあるのですが今回はまぁ基本的な部分ということで。

では、この基本的な流れに沿い、このアプリの裏側について解説していきたいと思います。

Crocosスケジューラ上で日程調整ページを作成する

日程調整ページの作成では、必須項目としてイベント名・詳細・候補日を設定します。

もしFacebookグループと紐付いたグループイベントを作成したい場合は、グループを指定します。

所属しているFacebookグループの情報の取得には、user_groups 権限を使います。

グループ取得のロジックはこんな感じで。

<?php $groups = $this->facebook->api("/me/groups"); // array // 0 => // array // 'version' => int 1 // 'name' => string 'Crocos マーケティング(懸賞・くじ) ユーザグループ' (length=6) // 'id' => string '279376552121236' (length=15) // 'administrator' => boolean true // 'bookmark_order' => int 2 // 1 => // array // 'version' => int 1 // 'name' => string 'Facebook API Developers JAPAN' (length=6) // 'id' => string '350715528292106' (length=15) // 'bookmark_order' => int 6 // ....

ちなみに自分が管理者になっているグループだけ取得したい場合は、'administrator' => boolean true というパラメータが入っているもののみ抽出すればよいです。

参加して欲しい人にイベントの招待（アプリリクエストまたはメール）を送る

友達に日程調整の招待をアプリリクエストで送ります。（アプリリクエストについてはまた追々..

招待された人は、日程調整ページから候補日の予定を回答する

○×△ボタンで候補日の予定を選択します。

参加できる人が多い日には背景の色がついたりするので、日程を決める際の参考になりますね。

イベント作成者は、回答を見て人数の集まりそうな日程でCrocosスケジューラ上からFacebookイベントの作成を行う

日程が決まったら、Crocosスケジューラ上からFacebookイベントを作成します。

GraphAPIでイベントを作成するには、/me/eventsにデータをPOSTします。

Facebookイベントの作成にはcreate_event権限と、 manage_pages 権限（作成するのがグループイベントの場合のみ）が必要です。

<?php $this->facebook->api('/me/events', 'POST', array( 'name' => 'イベント名', 'description' => 'イベント説明', 'start_time' => '開始時刻', // 現在時刻より後の時刻 'end_time' => '終了時刻', 'privacy_type' => '公開範囲', // OPEN, CLOSED, SECRET のいずれか 'location' => '場所', ) );

グループイベントの場合は上記と同様、/グループID/eventsにデータをPOSTすれば作成できる...と思いきや、実はこれではグループイベントは作成されず、個人イベントとなってしまいます。

グループイベントを作成するには、POSTするデータの中にpage_id => 'グループID'というデータを含める必要があります。ドキュメントにも書いてないので中々わかりませんね...

この仕様はLegacy REST API時代からの流れだと思いますが、イベント系のGraph APIはまだ結構手抜きっぽい部分が多かったりするので開発には苦労しています。

ちなみに上記のコードの/me/eventsのmeの部分はFacebook側であまりチェックしてないみたいで、meか適当な数字なら何でもよかったりします。

★イベント作成時に設定できる項目は他にも色々ありますのでドキュメントをご参照ください

以上でFacebookイベントの作成については終了です。

Tips

API経由でグループイベントを作成する場合、ユーザがグループの管理者になっていないと権限エラーが返ってきてしまうので、イベント作成前に必ず管理者であるかの確認を行うようにしてください。 通常、Facebook上から手動でグループイベントを作る場合はグループの管理権限は必要ないので、ここは整合性がとれていない状態です。

イベント系アプリの開発中は、作成するイベントの公開範囲をOPENにしないようにするか、自分のアクティビティを非表示にしておかないとテストイベントがどんどんフィードに流れたりして大変なので気をつけてください！（よくやりました

アプリを作る際、後の機能追加とかを色々考えてアプリ権限をたくさん取得したくなりがちですが、利用者の不安要素になってしまう可能性があるので、取得する権限はまずは最小限にしましょう。Crocosスケジューラは、開始当初はデフォルトで9個の権限を取得してましたが、現在は5個になってます。

[余談] Facebookの仕様変更により使えなくなった機能...

Crocosスケジューラでは、日程を確定してFacebookイベントを作成した時、ユーザの回答状況によって参加ステータスを自動的に更新しておくといった処理を行なっていました。（ユーザが参加可能で回答していたら、作ったFacebookイベントの参加ステータスも参加にしておく）

これはFacebookのoffline_accessという、access_tokenが長期間使えるようになる魔法のような権限を使って行っていたのですが悲しいことに2012年5月に廃止が決定してしまいました（実際に廃止されるのは10月みたいです）。悪用する例が多かったのでしょうか...

そのため、現在はFacebookイベントを作ったらユーザを招待するのみで、回答ステータスの自動更新はしない、という形になっています。

Facebookは割と頻繁にこういう思い切った仕様変更があるので、日頃から情報収集を頑張ってみるといいかもしれません。

イベント系のAPI はあまり使う機会はないかもしれませんが、今回ご紹介したのはほんの一部でこの他にも色々便利な機能が用意されているので、機会があればぜひお試しください！

CrocosスケジューラもAPIを活用しつつ、より使いやすくなるよう改善を続けていきますので、また機能追加などしたらお知らせいたします(^^)/