読者です 読者をやめる 読者になる 読者になる

Ancarに入社しました

あけましておめでとうございます。転職すると立て続けに扁桃炎になる呪いにかかっており、この年末年始も40度を超える熱を出してずっと寝てました。健康の大切さを定期的に思い知らされます。

転職しました

先日の PHP BLT #1 でも言いましたけど12月から Ancar で働いてます。転職先を聞かれて「アンカー」って答えると Anker にいくのかと真剣に勘違いされるケースもあったりしますが、 Anker 製品愛用していて Anker も大好きですのでいつか Ancar × Anker なコラボでもできたらいいなとか妄想してます。

Ancar は自動車の個人間売買のプラットフォーム(サービス名も Ancar)を開発しているスタートアップ企業です。僕自身が自動車業界に興味を持っていることに加え、コードを書く技術以外にも経営やチームづくりなどエンジニアとしての幅を広げられる環境に身を置きたいと考えていたところに友人経由で話が来て転職が決まりました。

エンジニアは1人だけ

僕が入るまでは正規のエンジニアが1人もいない状況でオフショアやインターンらにより開発が進められており、内部事情も中々に大変なことになっていたのですが、課題が沢山あるということはそれだけ解決すれば成長できるだけのチャンスがあるし、そもそもまだ憂うような規模でもないのでいいタイミングで入ったのではないでしょうか。

ちなみにインターンでがんばってくれてた方が正式に入社することが決まっていて、早速エンジニアが2人になるのでとてもうれしいです。

エンジニア募集中

とはいえエンジニア足りないので一緒にやってくれる方募集中です。特に iOS / Android エンジニアは今いない状況なので喉から手が出るほど募集してます。

自動車産業に革命を!技術で世界に挑むエンジニア募集! - 株式会社Ancarの求人 - Wantedly

僕はどんなサービスを開発していようと常に技術力で勝負できるプロフェッショナルなエンジニアでありたいと思ってますし、一緒に上を目指し続けられるようなメンバーと共に仕事ができればうれしいなと思ってます。

ヤフーのこと

2014年10月にクロコスがなくなってヤフー社員になり、その後ヤフーで色々やらせてもらったんですけど、僕はヤフーのこと好きだしまたいつか戻りたいなって本気で思ってます。

ヤフーは今大きく変わろうとしていて、特にエンジニアが今まで以上に気持ちよく働けるようにあれこれしている最中でした。僕も自分ができる範囲で活動してきたのですが、まだまだ今のままだとできる範囲が狭く実力不足を痛感し、また1から自分のスキルを再構築しようと転職に踏み切った次第です。

がんばります

Ancar はまだまだ軌道に乗るところまで行けてなくて毎日必死にやっております。自分自身も未熟な点がまだまだあって日々勉強です。応援よろしくお願いします。

ちなみに売り玉がまだまだ足りないので車売りたい方はぜひお声をおかけください。

ancar.jp

フレームワークの先へ / PHPカンファレンス関西2015で発表してきました

PHP カンファレンス関西 2015 に参加してきました。記憶が正しければ PHP カンファレンス関西は初参加なのですが、各セッションの中身が濃く、関西のコミュニティの方々の熱い思いがひしひしと伝わってきて、勉強にもなりましたし刺激も得られたので参加して本当によかったです。

conference.kphpug.jp

僕はフレームワークトラックで Symfony のセッションを担当させてもらったのですが、 Symfony の話ではなく「フレームワークだけではなく本質に目を向けよう」という内容になっています。


終わった後、多くの方に「よかった」と言っていただいて、うれしいとかではなくホッとしました。師匠も来られてたので、こんな話を肴のあてに終わったあとお話しさせてもらいまして、また色々なことを勉強させていただきました。

一部でエモいなどと言われてますが、思いの丈をぶつけられたのでスッキリしています。

実践ドメイン駆動設計

実践ドメイン駆動設計

ちなみにスライドの中でも紹介した「実践ドメイン駆動設計」、書店ブースで完売しててビビりました。とてもよい傾向にありますね。

書店といえば、登壇直後にサイン会をさせていただく予定が、登壇中の様々なプレッシャーにより終わった後そのまま無意識に LT を見に行ってしまい、開始が遅くなって申し訳ありませんでした。

余談ですがサインを待っていただいてた方がぼくと同姓だそうで「私も小川なんです」といわれたので「ぼくは高橋って呼ばれてます」っていったら 「(何言ってんだこいつ...)」 みたいな目で見られたのであまり余計なことは言わないようにしようと思います。

Symfony 2.7.0 released (Symfony Blog)

ついでに書いておくと Symfony 2.7 がでましたね。2.3 以来の LTS バージョンで 05/2018 までメンテナンスが行われるとのことです。PSR-7 対応Asset コンポーネントの追加Twigプロファイラの追加などが行われています。PSR-7 への対応は早かったというか、それにあわせたんでしょうけど、 Symfony の内部構造が拡張可能な形で設計されているからこそ環境の変化に柔軟に対応できるわけなんですね。

5月はスクーでオブジェクト指向の講義もやったりしてだいぶ登壇する機会が多かったのですが、ようやくこれで一段落。なのでこれから PSR-7 のあたりをしっかり勉強していこうかなと思ってます。セッション聞いてくださった方や支援してくれたカンファレンススタッフの皆さまありがとうございました。

今日の19:00からスクーでコードレビュー入門の授業をします

19時より生放送です。スクーにアカウント登録すれば無料で生放送見られますので、ぜひ登録して観ていってください。クリスマスプレゼントってことでひとつよろしくお願いします。

コードレビュー入門 小川 雄大 先生 - 無料動画学習|schoo(スクー)

PHP CS Fixerで快適PHPライフ

php

この記事は PHP Advent Calendar 2014 の8日目の記事です。

コーディング規約が守れない方とお悩みの方も、チームメンバーがなかなか守ってくれないとお悩みの方も、 PHP CS Fixer があればもう安心。PHP CS Fixer が PHP コードをコーディング規約に沿って整えてくれるので、秩序ある PHP ライフが約束されるでしょう。

そんなこんなで PHP Advent Calendar 2014 の 8 日目ですね。みなさんこんにちは、 fivestar こと小川です。いつのまにかクロコスがなくなって Y の人になっちゃいましたね。

昨今は PSR (PHP Standard Recommendation) の普及も進み、PHP 界隈にも統一感が訪れてきていますね。会社でコーディング規約を定める際、 PSR を基準とするところも増えてきていることでしょう。

ただ、コーディング規約を定めても、うっかり規約に沿わないコードを書いてしまう場合もあったり、コーディング規約の細部まで覚えられない場合や、どうしてもクセで間違えてしまう、なんて方も少なくないと思います。

組織によってはコードレビューを積極的に取り入れているところもあるかと思いますが、いちいち規約違反を指摘するのはもううんざり、なんて方もいるのではないでしょうか。

そんなときは PHP CS Fixer の出番です。

PHP CS Fixer とは

PHP CS Fixer (PHP Coding Standards Fixer) とは、その名の通り PHP コードをコーディング規約に沿うよう修正してくれるツール です。開発は活発に行われており、11月には v1.0 がリリースされました。現時点の最新バージョンは v1.2 がリリースされています。

PHP CS Fixer には標準で PSR-0PSR-1PSR-2 、および Symfony のコーディング規約 用の修正プログラムが用意されており、これらに準拠する場合はそのまま利用可能です。

ちなみに Symfony のコーディング規約は PSR-0/1/2 に準拠した上でさらにいくつかの規約を追加したもので、それらの上位規約として扱われ、 PHP-CS-Fixer のデフォルト に設定されています。

元々 Symfony のコアデベロッパーの Fabien Potencier 氏が開発したもので、前まで GitHub の fabpot ユーザが管理していたのですが、 最近 FriendsOfPHP に移管されたようです。

インストール

インストール方法は ドキュメント にいくつか書いてありますが、僕は Composer でインストールしてます。

% composer global require fabpot/php-cs-fixer
Changed current directory to /home/fivestar/.composer
Using version ~1.2 for fabpot/php-cs-fixer
...

Composer でインストールすると、 php-cs-fixer コマンドが利用可能になります。

ちなみに僕は ~/bin を Composer の bin-dir に設定してますが、デフォルトでは ~/.composer/vendor/bin あたりに入ると思うので Composer でインストールする場合は適宜パスを通す必要があります。

% composer config --global bin-dir "~/bin"

使い方

サンプル用に次のコードを用意します。これは PSR-2 の「名前空間の宣言直後に空行を入れる」「ブレス({ })は改行する」という2点に違反している状態です。

<?php
namespace Sample;
class Dummy {
}

このファイルが配置されたディレクトリ上で php-cs-fixerfix コマンドを実行すると対象に修正が行われます。 --dry-run オプションをつけることでドライランも可能です。次の例では対象を . にしているため、ディレクトリに含まれるすべての PHP ファイルが対象となります。

% php-cs-fixer fix . --dry-run --verbose --diff
F
Legend: ?-unknown, I-invalid file syntax, file ignored, .-no changes, F-fixed, E-error
   1) Dummy.php (line_after_namespace, braces)
      ---------- begin diff ----------
      --- Original
      +++ New
      @@ @@
       <?php
       namespace Sample;
      -class Dummy {
      +
      +class Dummy
      +{
       }
       
      
      ---------- end diff ----------

Fixed all files in 0.103 seconds, 5.250 MB memory used

level / fixers オプションで修正項目を制御する

デフォルトで (PSR-0/1/2 を含む) Symfony のコーディング規約に沿うよう修正が行われますが、内部的には項目が細分化されているため、例えば Symfony を基準にするが一部の項目は除外したいとか、 PSR-2 を基準に一部 Symfony の規約を追加したいとか、細かな制御も可能です。

項目の名称とか内容とかはたくさんあって書ききれないので ドキュメント を参照してください。ここを見るとどの項目がどの規約に準拠した内容かも確認できます。

前述のサンプルで取り上げた「名前空間の宣言直後に空行を入れる」「ブレス({ })は改行する」はそれぞれ「line_after_namespace」「braces」という名前の項目になっています。 fix コマンドに --verbose オプションをつけるとどの項目が適応されたか一目でわかるので参考になるかと思います。

PHP CS Fixer では psr0 < psr1 < psr2 < symfony のようにレベルわけされており、上位は下位を含む扱いとなっています。そのため PSR-0 および PSR-1 の項目のみで修正を行いたい場合、次のように --level=psr1 を指定すると、 PSR-0 および PSR-1 に分類される項目のみが実行されます。

% php-cs-fixer fix . --level=psr1

さらに psr1 に加えて line_after_namespace 項目を指定したい場合は --fixers=line_after_namespace を指定します。

% php-cs-fixer fix . --level=psr1 --fixers=line_after_namespace

psr2 から bracesvisibility を除いた項目のみ実行したいといった場合、項目名の先頭に - をつけて指定します

% php-cs-fixer fix . --level=psr2 --fixers=-braces,-visibility

このように level / fixers オプションを組み合わせることで、組織やプロジェクトごとの規約に沿った修正が実現できます。

.php_cs による設定管理

これらの指定は毎回しなくても、 .php_cs ファイルを用意することでデフォルトの挙動を設定しておくことが可能です。たとえば前述の最後のコマンドを設定化すると次のようになります。

<?php

return Symfony\CS\Config\Config::create()
    ->level(Symfony\CS\FixerInterface::PSR2_LEVEL)
    ->fixers(['-braces', '-visibility'])
;

.php_cs ファイルが配置されたディレクトリ上でコマンドを実行するか、 --config-file オプションで .php_cs へのパスを指定すると .php_cs が読み込まれるようになります。設定ではこの他にも、検索対象のファイルの指定や自前の項目の追加なんかも可能です。 ドキュメント にもう少し詳しく使い方が書いてあるのでやりたいことが他にある方は見てみるとよいでしょう。

基本的な使い方はこの辺を覚えておけば十分かと思います。あとはどの項目を適応するかの選択かなと思います。

一応、項目のロジックは自分で追加/拡張できるんですけど、トークン化したコードを正規表現なんかも駆使してゴリゴリやってるので、まあその辺用意するよりは素直に PSR や Symfony の規約に合わせちゃうのが楽だと思います。せっかく標準化を進めてるわけですからね。

もし組み合わせた場合の挙動を詳しく知りたい方がいたら、 ConfigurationResolver のテスト を見てみるといいかと思います。

ちなみに以前に「追加の指定と除外の指定を同時にした場合にうまく適応されないバグ」があって、実はその辺を僕が Pull Request を送って修正した んですけど、ちょろっと修正するつもりがオプションとか設定関連なんかをついでにってことであちこち修正させられて、結局1ヶ月くらいかけてやりとりしながらなんとか取り込まれたという思い出がありまして、そんなこともあったので今回このネタにしたんですけど、せっかくなので記事の最後に思い出話も書いておきますので興味ある方は読んでみてください。

PHP CS Fixer を Git のコミットフックに設定する

PHP CS Fixer が使えるようになったからといって実行されないと意味ないので、エディタの保存時に実行するようにするとか、何かにつけて実行されるようにしておくのがよいかと思います。

クロコスのときは、 Git のコミットフックでコミット対象のファイルに対して PHP CS Fixer が実行されるように設定していました。一応 Gist に pre-commit ファイルを置いておきます。ちなみにオプションの指定は適当です。使われる場合は好きなように変えたり、 .php_cs ファイルを用意するのがよいかと思います。

https://gist.github.com/fivestar/7b2491c633d7476fa33f

元々 sotarok が GREE 時代に書いていた、コミット対象に php -l を実行するフックを拡張したもので、対象にコーディング規約違反があると、修正した上で diff を表示してコミットを中止する、ということを行っています。中止しているのは、以前想定外の修正が行われてプログラムがバグったことがあったので内容を確認してから add するなり修正するなりしてね、という意図があるためです。

% git add Dummy.php
% git commit
CS fixed:
F
Legend: ?-unknown, I-invalid file syntax, file ignored, .-no changes, F-fixed, E-error
   1) /home/fivestar/sample/Dummy.php (line_after_namespace, braces)
Fixed all files in 0.121 seconds, 5.250 MB memory used
diff --git a/Dummy.php b/Dummy.php
index 62721b7..5e5873a 100644
--- a/Dummy.php
+++ b/Dummy.php
@@ -1,4 +1,6 @@
 <?php
 namespace Sample;
-class Dummy {
+
+class Dummy
+{
 }
  
----
git pre-commit hook error
...

エディタで設定するかどうかは基本各自に任せていたので、最低限これを入れて防げるようにだけしていました。一応クロコスのときはリリース前に必ずコードレビューが入るようにしていたので、そこで規約違反見つけたら設定漏れてるかどうか確認したりはしていました。

このようにどこかのタイミングで必ず実行されるようにしておくと、コードレビュー時に最低限規約に沿った状態から始められるので余計なチェックをしなくて済むのでおすすめです。

一応ドキュメントに エディタ用プラグインリスト があるのでエディタに設定しておきたい人はチェックしてみてください。

Pull Request 送った時の話

蛇足かもしれませんが、前にちょこっと触れた通り、 Pull Request を送った時の話を少し書いてみます。

repo owner の話

このプロジェクト、 keradus ってポーランド人が活発に動いていて、彼とずっとやりとりしていたんですけど、彼についてすばらしいなと思ったことがありまして。彼は基本的にこちらの活動を褒めた上で、指摘や要望をあげるんですよね。あと1週間くらい修正を放置すると催促の連絡がくるんですけど、その内容も前向きで「いい感じにできてきてるから続報待ってます!」のような感じなんです。

特に OSS に関わる人の多くはボランティアとして活動しているだけに、モチベーションがエネルギーに繋がると思うんですけど、彼はそこのコントロールがうまいなあと思いました。さらに相手のモチベーションをなるべく下げないようにしつつ、別の要望を言ってくるんですよね。おかげで僕は既存のいけてない部分をあちこち直す羽目になったんですけど、まあそうやってうまくリソースを使って開発を継続的に進めていくということは大切だなと改めて思いました。実際のところ本人がどう思ってたのかはわからないんですけどね。

英語の話

PR を送ってコード修正するのは別に大したことではなかったんですけど、 README に説明書き足してくれって言われちゃって、まともな英語かけるかなあなんて最初はビクビクしたんですけど。結局てきとうに書いて送ったら一応意味は通じたっぽくて、 the つけろとか細かい指摘もらったのであとはもう言われるがままに整えて一応なんとかなりました。

英語が得意じゃなかったとしても、とりあえずそれっぽく書いておけば誰かが指摘するなり直してくれたりするし、やるだけやってみるとよいと思いました。

ただまあ README だけじゃなくて、 Pull Request 自体全体でコメント 80 件以上ついてるように結構なやりとりをしなければならなくて、そこにだいぶ時間をとられたなーとは思ってるので、英語力を鍛えるのは課題だなあと改めて認識しました。

まとめ

なんかさらっと終わらせるつもりだったんですけどだいぶあれこれ書いちゃいました。その労力をパーフェクト PHP 改訂版に回せって話ですね。すいませんがんばります。来年にはきっと..

さてさて、 PHP CS Fixer を活用すればコーディング規約を準拠するコストがぐっと抑えられることが伝わったらいいなーと思います。あとはまあ PSR の採用が進むといいなと。

PHP CS Fixer は使い方自体は簡単で、あとはどう設定するかだと思います。ドキュメントは1ページでだいたいまとまってるので、何かあったらドキュメントを見てみるのがよいでしょう。

最近 Go でスクリプト書いたりしてるんですけど、 Go には標準で gofmt ってのがあって細かいこと気にせずにコードかけるんで、どんな言語であれ規約に沿って自動的に直してくれるツールは積極的に導入していきましょう。

宣伝

直接は関係ないんですけど、今度 スクー でコードレビューについてお話しさせていただく予定です。日付とかまだ調整中なんですけど、決まったらまた告知するんでよかったらみてください。

追記

12/24 19:00 に決まりました!ぜひ見ていってください。

コードレビュー入門 小川 雄大 先生 - 無料動画学習|schoo(スクー)

P.S.

そういえば PHP_CodeSniffer とかどうなってるのかなーと思って今みたら 12/5 に 2.0 がリリースされたばかりっぽくて、いまでも開発続いてるみたいなんで使いたい人は使ってみればいいんじゃないでしょうか。

OS X YosemiteのJapaneseIMでバックスラッシュを入力する

OS X Yosemite の JapaneseIM の仕様で、バックスラッシュ(\)がデフォルトで円マーク(¥)を入力するように設定されているので備忘録を残しておきます。エンジニア(特にPHPer)的には困った変更ですね。

f:id:Fivestar:20141021012835p:plain

f:id:Fivestar:20141021012829p:plain

nanapi勉強会 vol2 に参加してきました

event

めも


そうたろう

  • cocoiti さん、目で dis られる
  • シェルをもっと効率的に使って作業しよう
  • 武器を増やそう
    • シェルの超基本
      • C-a とか C-e とか C-w とか使ってカーソル移動を効率的に
    • screen とか tmux とか当然使おう
      • それ上でコピペできるようになっておくとよいよ
    • .zshrc とか
      • いつも煩わしいと思ってた作業が簡単になるやつ!
        • 定着する
      • よさそうだから入れてみよう!
        • たいてい定着しない
    • インクリメンタルサーチ
      • C-r
      • 例えば git pull --rebase origin master と打ちたい場合、
        • pull あたりで C-r して過去のやつ引っ張ってくるとか
    • 同じことの繰り返しをさける!
  • 他人の作業に興味を持とう
    • まわりでシェルさばきの優れた人を見つけて色々聞いてみる

wadap

VOYAGE GROUP PR

  • 無料で セミナールーム社内バー AJITO を貸してます
  • 無料シェア会議室 PORT
  • 懇親会スポンサーもやってます
    • sponsoring ピザ / すし / ビール
  • その代わり PR させてね
  • エンジニア募集中!!!

ゆにこさん

  • 少々黒い画面を嗜むデザイナー
  • どうやって黒い画面とお近づきになれたか
  • きっかけは Git (*Hub ではない)
  • コマンド覚えてよかった
    • 誰に聞いても同じ
    • history に残る
    • エンジニアと会話できる
    • Win から Mac に移動しても問題なし
    • 黒い画面こわくない
  • まとめ
    • デザイナーでも黒い画面つかえると得するよ
    • エンジニアと同じ目線では話せるといいよ

id:rx7 さん

  • hef実践入門
  • History に残ってるコマンド実行数ランキング
    • history | awk '{print $2}' | sort | uniq -c | sort -nr
  • ignoreeof
    • シェルの入力終了を防ぐ
  • errexit
  • xtrace

こにしさん

_人人人人人人_
> ピザ到着 <
 ̄Y^Y^Y^Y^Y ̄

はらへった

@nashibao さん

  • fishシェル
  • suggest が最初からあるよ
  • sjl/z-fish
  • bpinto/oh-my-fish
  • いろいろいれると zsh と同じことができるよ
  • zsh よりいいことないの
    • ウェブの設定画面があるよ
    • 何するの
      • 色とか変えられたりするよ...
      • マージンも変えられるし...
        • CSS でやればいいだろ
_人人人人人人人人人人人_
> CSSでやればいいだろ <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄

naoya さん

Composerを使った簡単Travis CI設定

php phpadvent2013

これは PHP Advent Calendar 2013 - Qiita [キータ] の5日目の記事です。

みなさんこんにちは。fivestarことクロコスの小川です。

Composerを使うと簡単に依存ライブラリを管理することが可能です。Composer とはなんぞや、という方は下記の記事あたりに目を通してみてください。

Composerを活用したモダンな開発手法をPHPカンファレンス2013で発表してきた。 #phpcon2013 | Engine Yard Blog JP

Composerでは例えば次のようにcomposer.jsonファイルを書くことで依存ライブラリを指定できます。この例だとFacebookPHP SDKが使えるようになります。

{
    "require": {
        "facebook/php-sdk": "dev-master"
    }
}

Composerとオートロード

Composerを使うポイントの1つに、オートロードが自動設定される点があります。つまり、requireを書いたり、spl_autoload_register()を書いたりすることなくライブラリのクラスが呼び出せるようになる、ということです。Composerを使ってライブラリをインストールするとvendor/autoload.phpというファイルが自動的に作られるので、それを読み込むだけで外部ライブラリのオートロードが有効になります。シンプルですね。

なので、テストの際もphpunit.xmlにvendor/autoload.phpを読み込むように記述しておけば、オートロードが有効になった状態でテスト可能です。

<?xml version="1.0" encoding="UTF-8"?>
<phpunit bootstrap="./vendor/autoload.php" colors="true">
  <testsuites>
    <testsuite name="hogeee">
      <directory suffix="Test.php">./Tests</directory>
    </testsuite>
  </testsuites>

  <filter>
    <whitelist>
      <directory>./</directory>
      <exclude>
        <directory>./vendor</directory>
      </exclude>
    </whitelist>
  </filter>
</phpunit>

従来であれば、各ライブラリがオートロードの仕組みを独自で実装していたのですが、Composerがオートロードの仕組みも含めて管理してくれるため、利用者は1ファイル読み込めばよくなり、すごく楽になっています。

require-dev

Composerを使うと、開発時のみに読み込みたいライブラリの指定も可能です。それはcomposer.jsonにて次のように指定します。"require-dev" というのがそれです。

{
    "require": {
        "facebook/php-sdk": "dev-master"
    },
    "require-dev": {
        "phpunit/phpunit": "3.7.*",
        "phake/phake": "2.0.*@dev",
        "piece/stagehand-testrunner": "3.6.*"
    }
}

この例だとPHPUnit、Phake、Stagehand_TestRunnerを開発時のみインストールする、という指定です。このようなテスティングツール系は運用時には基本的に不要なので、require-devに含めておくのがよいです。

なお開発時のみ、という判定はインストール時に--devオプションを指定することで行います。

% php composer.phar install --dev

(追記) --dev がデフォルトでつくようになっていたらしい。今は逆に、require-devを含めたくない場合に--no-devつけろってことでした。 @hidenorigoto @brtriver ご指摘ありがとうございます!

Composer: Installing require-dev by default

Composer: Installing require-dev by default - Jordi Boggiano

参考までに、僕が作っているCrocosSecurityBundle というライブラリは次のようにrequire、require-devを設定しています。

{
    ...
    "require": {
        "php": ">=5.4.0",
        "symfony/framework-bundle": "2.3.*@dev",
        "symfony/http-foundation": "2.3.*@dev",
        "doctrine/common": "2.2.*"
    },
    "require-dev": {
        "symfony/config": "2.3.*@dev",
        "symfony/dependency-injection": "2.3.*@dev",
        "symfony/doctrine-bridge": "2.3.*@dev",
        "symfony/event-dispatcher": "2.3.*@dev",
        "symfony/http-kernel": "2.3.*@dev",
        "doctrine/orm": ">=2.2.3,<2.4-dev",
        "facebook/php-sdk": "dev-master",
        "phake/phake": "2.0.*@dev"
    },
    ...
}

そもそもこのライブラリはSymfonyのバンドルっていう、まあプラグインみたいなもので、基本的にSymfonyに組み込んで使うものなので、Symfonyがあればいいんです。とはいえ開発時にはテストをする必要があります。いちいちSymfonyに組み込んでテストするのも大掛かりで煩わしいので、Symfonyの中で使っているコンポーネントをrequire-devに入れておいて、Symfonyに組み込まなくても自力で依存しているSymfonyコンポーネントをインストールしてテストできるようにしています。

その他にも、Doctrine ORMやFacebook PHP SDKと連携する仕組みも提供していて、これは使いたい人だけ使えよっていう機能なの該当のライブラリはrequireに入れていないのですが、やはりテストは書いておきたいのでrequire-devに指定しています。

あ、ちなみにCrocosSecurityBundleはid:Yudoufuの協力もあってSymfony2.3にようやく対応しました。ゆどうふありがとう。

Travis CI

Travis CIはGitHubのリポジトリをCIするためのサービスで、ご存知の方も多いかと思います。

こういうやつです。
f:id:Fivestar:20131205124618p:plain

サービスフック設定をして、リポジトリに.travis.ymlを入れておくと、自動的にテストをしてくれるやつです。インストール方法はGetting startedをみればわかるっていうか画面をポチポチしてればほとんどやってくれちゃうのでまあやってみればよいです。

f:id:Fivestar:20131206125740p:plain

Travis CIではcomposerがプレインストールされているため、.travis.ymlに次のように書くだけで、自動的にライブラリをインストールしてPHPUnitを実行してくれるようになります。(オートロードはphpunit.xml.distで設定している前提です)

language: php

before_script:
    - composer install --dev

php:
  - 5.4
  - 5.5

Packagist

おまけ。Packagistっていうのは、Composerでインストールできるライブラリのリポジトリです。こいつもGitHubと連携していて、GitHubにあるリポジトリを簡単に登録することができます。せっかくなので、登録方法を簡単に紹介します。

Travis CIは設定を.travis.ymlに書きましたが、Composerはcomposer.jsonにライブラリの説明などを記述します。CrocosSecurityBundleだったら下記みたいに書いています。

{
    "name": "crocos/security-bundle",
    "description": "This bundle provides a way to configure security with annotations",
    "keywords": ["annotations","security","authentication","authorization"],
    "type": "symfony-bundle",
    "homepage": "https://github.com/crocos/CrocosSecurityBundle",
    "license": "MIT",
    "authors": [
        {
            "name": "OGAWA Katsuhiro",
            "email": "ogawa@crocos.co.jp"
        }
    ],
    ...
}

簡単に説明しておくと、下記のような内容を書いておきます。

  • name: パッケージの名称。ベンダー名/ライブラリ名 形式
  • description: 説明
  • keyword: タグを配列で指定
  • type: だいたい "library"
  • homepage: Webサイト。なかったらGitHubのURLでいいと思います


何かいていいかわからなかったら、Composerのリポジトリブラウザで適当に同じようなやつ探してまねればいいと思います。

で、とりあえず書き終わったら次のコマンドでチェック。is validとでれば大丈夫らしいです。

% php composer.phar validate
./composer.json is valid

そこまでできたらGitHubにpushして、あとはPackagistにGitHubのリポジトリを登録します。Packagist内でそこら中にある「Submit Package
Packagist」をおして登録画面にいき、リポジトリのURLを登録します。登録したときのこと忘れたんですが、HTTPSで登録した気がします。 (https://github.com/xxx/xxx.git)

あとはcomposer.jsonを勝手にみてうまいことやってくれます。

https://packagist.org/packages/crocos/security-bundle

で、Travis CIと同様、Packagistもサービスフックを設定することで、pushするたびにPackagistの情報も自動更新されるようになります。登録したGitHubリポジトリのSettingsからService Hooksを開き、Packagistを選んでAPI Tokenの登録をします。API TokenはPackagistのマイページ(右上のユーザ名のリンク)からYour API Tokenのところにあります。

f:id:Fivestar:20131205124707p:plain


さてさて、たいした内容ではありませんでしたが今回はここまで。Composer関連はその辺のPHPライブラリのcomposer.jsonみればいろいろヒントが書いてあるので、いっぱい探してみましょう。

次は @hidenorigoto さんのMVCの記事ですね。楽しみですね。

追記:

実装の問題としてクラスの関係がどうだとか、どことどこに関連があるのが正しい/間違いだとかいうレベルのことではないのです。ソフトウェアがどういう構成になっていればよいのかを抽象的に示したものなのです。

PHPメンターズ -> Beyond MVC

期待通り、すばらしい記事でした。