PHPMatsuri へ向かいます。
今年は札幌でございます。

PHPMatsuri2013

a0782_000692

PHPMatsuri Tokyo (2010) から、参加し始めて
Osaka (2011), Fukuoka (2012) と完全リピーター状態の私です。

というわけで、個人的な見どころ、挑み方メモ

http://www.phpmatsuri.net/2013/timetable.html

なんといっても楽しみなのは、 Mitchell Hashimoto さんの、
Vagrant 話。Vagrant は 仮想マシン構築・設定の自動化のための
ツールです。私も大変お世話になっております。
昨日も、Meetup があったそうですが、明日はまた違った話が聞けるという
噂があります。

そして、毎年おなじみ Graham Weldon さん。なんと去年より、弊社で
働いており、内製PaaSの開発を行なっております。
PHP での PaaS の話が聞けると思いますよ!

夜中には謎のイベントである「闇」が開催されます。
去年は、レガシー戦隊が登場しましたが、今年は何が起きるんでしょうか。

月曜日はコンテストがあります。これは、エントリーした人が
今回のハッカソンで行ったことなどを発表する会です。
毎年、豪華な景品たちが用意されています。

これは、参加者の皆さんはぜひともエントリーしてください。
エントリーしないと損です!!ハッカソンで作れなくても
失敗したことや、PHPamtsuri に参加した感想なども
とても歓迎されます!

あと、やばい時は寝た方がいいです。

Posted in PHP.

こんにちは。Ooharabucyou こと、川原であります。
技術ブログ強化中です。飽きるまで週一で情報発信をしていく次第です。
今までやってなかった、Groovy, Grails, Gradle といった G* シリーズも
ちょくちょくやっていこうかなとおもいます。

本日は、前回の記事でちょこっと出ていた satis についてです。
satis は、composer パッケージのレポジトリを静的なコンテンツで作成してくれる
ツールです。

公に公開するものであれば、packagist.org に登録をすればよいのですが、
社内向けプロジェクトやライブラリはそういうわけには行きません。
そこで役に立つのが、このプロダクトです。

このプロダクトの優れているところは、
対象のパッケージに依存する(packagist.orgなどの)パッケージも、同じレポジトリに入れてくれる
機能が存在することです。

社内でこれを利用した場合、社内の利用プロジェクトは packagist.org
に接続しなくても良くなるので、スピーディーな開発プロジェクトセットアップ
が期待されます。

実際に使ってみましょう。

ドキュメントにある通り、プロジェクトを作成します。

composer create-project composer/satis --stability=dev --keep-vcs

composer –keep-vcs オプションは、プロジェクト作成時に使うと、
git の場合 git clone & composer install した状態と同じになります。
付けない状態だと、ソースコードの入手からの場合、 .git or .svn を削除するか
聞かれます。 (2013/07/06 version=ab731b1197d76ce1e13fbf67a7e8f17a2be8b3e9)

satis 自体の入手はこれで完了です。次は composer.json を含む
対象のプロジェクトを用意しましょう。今回は、symfony-standard を例に使います。

対象のパッケージ情報について記した config.json を作成します。
とりあえず、satis と同じディレクトリに置いてみましたが、どこでも構いません。

{
    "name": "Symfony Standard (Internal)",
    "homepage": "http://symfony.com/",
    "repositories": [
        { "type": "composer", "url": "http://packagist.org" }
    ],  
    "require": {
        "symfony/framework-standard-edition": "v2.3.1"
    },  
    "require-dependencies": true
}

repositories では、レポジトリの指定を行います。
今回は、composer を指定していますが、社内の VCS レポジトリを指定する場合は

{ "type": "vcs", "url": "gitなどのパス" }

とできるわけです。

“require-dependencies” を true にすると、依存するライブラリも
一緒にレポジトリに入れます。

最後に、satis の bin ディレクトリに satis コマンドがありますので
build を実行します。先ほど作成した、 config.json と、完成した
レポジトリを格納するディレクトリ (以下の例では web) を指定します。

Github のAPIコール制限に引っかかる場合もありますので、その場合は
ユーザ名とパスワードを入力すると良しです。

./bin/satis build config.json web

… と暫く待っていると、出来上がりです。
web ディレクトリに展開されています。

PHP のビルドインHTTP Server で公開して確認

php -s localhost:9999 -t web

.composer のキャッシュを削除して composer install の時間を
測定してみます。

まずは、通常の状態で

composer create-project  symfony/framework-standard-edition --profile

293.56s かかりました。

次に、 .composer/config.json を少しいじくってから検証します。
以下のようにすると、packagist.org が無効化されます。
(こうなってくると、無効化のオプションとかがほしくなるぜ。)

{
    "repositories" : [ 
        {"packagist" : false },
        {"type" : "composer", "url" : "http://localhost:9999/"}
    ]
}

その上で、再度実行

composer create-project  symfony/framework-standard-edition --profile

77.87s

だいぶ早くなりました。

いまのところ、zip ファイルは、Github から取得しに行っていますが、
satis では、repository と一緒に公開する機能を搭載しています。

{
    "name": "Symfony Standard (Internal)",
    "homepage": "http://symfony.com/",
    "repositories": [
        { "type": "composer", "url": "http://packagist.org" }
    ],  
    "require": {
        "symfony/framework-standard-edition": "v2.3.1"
    },  
    "require-dependencies": true
}

バージョン指定が範囲指定されているため、考えられるすべらのバージョンを
アーカイブします。framework-standard-edition の依存を
アーカイブしようとしたのですが全然終わりません。。。

ひとまず、アーカイブまではしなくてもよさそうなのでここまでにします!

Posted in PHP.

お久しぶりです。Ooharabucyou でございます。
当ブログの存在をすっかり忘却しておりましたが、みなさまお元気でしょうか。

最近は、本業ではもっぱら GroovyGradle と戯れる日々なので
PHP については、暫く触っていませんでしたが、
PHPMatsuri も近づいておりますので、201千葉コーワーキングにこもり
こうして準備をしているわけでございます。

さてさて、久しぶりの話題は composer でございます。
去年の PHPConference などでも、以下の様な話題で composer の
布教活動などをしました。

あれから、10ヶ月。Github に composer が登場してから、まもなく2年となろうとしております。
PHP勉強会などに参加すると、だいぶ普及してきたように思えます。
Symfony だけでなく、様々なプロジェクトで活用されている成果なのでしょう。

pear でのライブラリ管理よりは(自分の中で)ずっと快適なのですが、
まだ不満はあります。

その一つ、特に囁かれる問題が、遅いという点です。

現在のcomposer の動作をソースコードの確認や -vvv オプションの付加により
なぜ遅いのかを考えてみます。
update 時に -vvv をつけると、より詳細なログが
標準出力に出てくるので、デバッグなどに便利です。

そうすると、見た感じから、以下がストレスを作る原因と考えられます。

遅い1) Package情報の入手

標準では、packagist.org からパッケージを入手する仕組みになって
いますが、この動作は現在2つに分類されます。
1つは、 /packages.json の入手です。このファイルには、
どのように参照すれば実際の依存情報を記したファイルが手に入るのか
という情報を記しています。
このダウンロードは毎回行われますが、さほど時間はかかりません。

問題は次です。上で入手した情報を元に依存情報の収集に向かうのですが、
これが、初回の場合大変時間がかかります。
(プロジェクトの規模によるかと思いますが、Symfony2 で動くプロジェクトであるpackagist の場合、
情報の取得だけで 17MB, 145個のファイルをせっせとダウンロードしていたのでした。)

2回目の場合は、cache から収集するため、 ずっと早くなります。
cache はデフォルトで 6ヶ月有効です。cache の場所は デフォルトでは
$HOME/.composer/cache/ なので、覗いてみるといいかもです。

遅い2) ソースコードの入手

これは、パッケージの定義によりけりです。
通常、安定したバージョンであれば、Github のアーカイブ (zip) から
入手されます。こちらも同様にキャッシュされます。
ただし、開発ライブラリなどであれば、gitレポジトリから clone
する場合が多いため、こちらがなかなか時間がかかります。
(こちらはアーカイブの場合キャッシュされます。
そのため、2回目は早くなります。)

これを踏まえた上で、解決案を考えてみた。

解決案) packagist.org JP Mirror or Proxy を作る

Tokyo から packagist.org まで 300ms – 500ms ほどの
レイテンシが存在するのです。
このサーバは、France にあるようです。ちょっと遠いですね。。。
日本のどっかにサーバを置くことで早くなるんじゃないかという説。

packagist に Nexus (Maven Repository/Proxy) みたいな Proxyの仕組みがあると嬉しいのですが。
* 参考記事: リポジトリ管理ツール「Nexus」でMavenをさらに活用しよう!
そこら辺は、改造のやりがいがあるかもしれないです。

【追記】
なお、社内ライブラリやプロジェクトの配布については
composer/satis を使うとよさそうです。
このツールは、Composer Repository のビルドツールです。

ちゃんと設定すると、packagist.org 上の依存ライブラリのアーカイブを
自分のサーバで配布することができます。

自身のプロジェクトで、自分で用意した Repository を使い、
packagist を無効化すると、かなり高速化されます。

あとで、これについての記事を書こうとおもいます。