今日も適当ダイアリー

第89回PHP勉強会＠東京でBEAR.Sundayのお話をしてきました #phpstudy

2015-04-30T20:00:00+09:00

blogger からはてなブログに移行したんだけど、面倒だから適当に移行して以前の記事が 404 Not Found になってたりしてごめんなさいな @madapaja です。

もう4月も終わりますね。やること、やりたい事が多くて時間が足りてません。

さて、先日 4月28日にリジョブ咲くらぼで第89回 PHP勉強会＠東京が開催されました。

勉強会の内容は、PHP勉強会＠東京で恒例となっている参加者全員での自己紹介から始まり、セッション、懇親会＋LTと約2時間半程度でした。

参加者は使い始めたばかりの方からPHP歴10年以上のベテランまで、バックグランドも経験も様々な人が集まっていろんな話をしました。久しぶりに参加したのですが楽しかったです。

会の詳細は、togetter でのまとめとか、Twitterあたりで素敵なまとめブログとかが出てくるんじゃないかと思いますので、そちらを要チェックです。

で、私は BEAR.Sundayのはなしというタイトルで発表してきたので、そちらの内容のまとめを書きたいと思います。

BEAR.Sundayのはなし

BEAR.Sunday = DI + AOP + REST(Hypermedia)

BEAR.Sunday は DI、AOP と REST(Hypermedia) という3つの仕組みが柱となっているリソース指向フレームワークです。

DI、AOP、REST(Hypermedia) はそれぞれ Ray.Di、Ray.Aop、BEAR.Resource というフレームワーク（ライブラリ）が用いられており、すべて BEAR.Sunday の開発者でもある郡山さん（@koriym）を中心に開発されているものです。

DI と Ray.Di

Ray.Di は、Module という単位でルールを記述（どういう構造なのかを示す）すると、そのルールを基にオブジェクトが生成出来る DI フレームワークです。ルールを一度記述すれば、同じルールで表現できるDIであれば、別のクラスなどで利用する際にも、新しい設定なしに必要な依存オブジェクトが注入されるため、よりクラス同士の密結合を減らせます。

Ray.Diについては、以前にブログを書いていますので（ちょっと古い内容ですが、根本は変わっていないので）参考になるかもしれません。

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻其の壱 - 今日も適当ダイアリーblog.madapaja.net

なお、Ray.Diは最近リリースされたバージョン2.1から、インスタンス生成コードの自動生成への対応が行われ、よりパフォーマンスの向上が期待できます。

AOP と Ray.Aop

Ray.Aop は横断的関心事を分離するためのアスペクト指向フレームワークです。インターセプターという仕組みを利用して、横断的関心事を本質的関心事と切り離し、それを結びつけることができます。

Ray.Aop についても過去の記事がありますのでもっと知りたい方は見てみてください。

BEAR.Sunday meetup #0 でRayについて話してきました #BEARSunday - 今日も適当ダイアリーblog.madapaja.net

Ray.Aopもバージョン2.1からコード生成部分の効率化が図られ、より使いやすく進化ました。

REST(Hypermedia) と ROP（リソース指向プログラミング）、BEAR.Resource

PHPの多くのフレームワークとの大きな違いは、MVCではなく、リソース指向を選択している点でしょう。

皆さんも Web を日々利用していると思いますが、その凄さは何なのでしょうか？その凄さの一つに、REST、Hypermediaによってもたらされる拡張性、柔軟性、ポータビリティの高さ等があると思います。

BEAR.Resource では、1つのURLを1つのクラス（リソースオブジェクト）と対応させ、それらのリソースをRESTと同じように扱おうとするフレームワークです。

リソースは URI とクエリなどによってリクエストを行い、<a>タグや<link>タグのようにリソース同士をリンクしたり、<img>タグや<video>タグのようにリソース内に別のリソースを埋め込む事ができます。

また、MVCのようにコントローラがモデルからデータを受け取りView渡すのではなく、リソースに対するリクエストに対して、リソース自身がレンダラーを持っており、それによって表現、アウトプットする、というのも特徴的だと思います。

まとめ

BEAR.Sunday は DIで構造を結びつけ、AOPで横断的関心事を結びつけ、ROP（REST, Hypermedia）でリソース同士を結びつけるConnecting Framework と言うことも出来ます。

また、RESTの力を引き出し、それをアプリケーションにも適用することで、広がる世界は面白いと思いませんか？

だって、Webの凄さはみんな知っているでしょ？

興味を持たれた方は、ぜひ一緒に BEAR.Sunday 触りましょう！

質問

勉強会で質問されたことをこちらでもまとめておきます。

BEAR.Sunday の由来は何ですか？

（会場では言えませんでしたが）

Because Everything is A Resource

Sunday なのはクマの名前から、というのは、アドベントカレンダーで郡山さんが書いていたのでチェックしてみてください！

どの程度の規模のアプリに適していますか？

スケールについては Web と同じです。つまり、最小から極大までに対応できます。

速度面については、HelloWorldベンチが以下にあるので実際に図ってみてください。（誰かベンチしたらぜひシェアしてください！）

bearsunday/BEAR.HelloWorld · GitHub

参考URL

BEAR.Sunday meetup #0 でRayについて話してきました #BEARSunday

2012-07-20T12:07:00+09:00

こんばんわ。BEARでBEERな @madapaja です。

7/19に行われた BEAR.Sunday meetup #0 に参加して BEAR のオブジェクトフレームワークである Ray について発表させていただきました。

最初に、会場を提供していただいたVoyage Groupさん、ありがとうございました。そして、スピーカーの皆さん、参加者の皆さん、スタッフの皆さん、本当にお疲れ様でした！また、@koriym さんには発表前から後までフォローいただき非常にお世話になりました。ありがとうございました。

ということで、まだ開発途上のPHPフレームワーク「BEAR.Sunday」の勉強会ということでしたが、野心的でパワフルな方々が参加され、非常に面白い勉強会でした。
アットホームな雰囲気で、濃い話が聞けたのはとても良かったです。

私自身、BEAR.Sundayについて直接聞くのは、昨年末の前々回のSymfony勉強会、先月のSymfony勉強会に続いて3度目でしたが、やっとのことで、BEARの考え方がある程度理解できました。やっとスタートラインに立てたかな、などと思っています。
といっても、じゃあ他の人に説明してみて、と言われたらまだ出来ないので、これからも継続的にウォッチしたいとは思います。

Ray.Di / Ray.Aop コトハジメ

「Ray.Di / Ray.Aop コトハジメ」というタイトルで発表した内容は、スライドを見ればなんとなく分かるかと思いますが、スライドには書ききれなかったことを補足したいと思います。

当日使った資料とあわせてご覧ください。

BEAR.Sunday

以前、郡山さんからこんなDMをもらいました。

「ポイントは問題の解決に実装ではなく設計で挑もうとしてる点です。
これが開発リソースの細い細い僕が挑める唯一の方法です。」(@koriym)

この言葉にもある通り、BEAR.Sundayには多くの挑戦があり、多くの設計に関するキーワードがあります。

BEAR.Sundayを取り巻くコンセプトやアーキテクチャ、技術などは様々あります。（ここには書き切れませんし、説明し始めたら1日でも終わらないと…）その中で、BEAR.Sundayのコアフレームワークの一つである Ray の紹介を行いました。

(BEAR.Sunday Note より)

Ray (rayphp)

Rayは、DI（依存性の注入）をサポートするRay.Diと、AOP（アスペクト指向プログラミング）をサポートするRay.Aopの2つのフレームワークから構成されています。

Rayの役割は、オブジェクトの面倒をみることです。つまり、DIでオブジェクトの生成を行い、AOPによって振る舞いを変更することでオブジェクトを利用します。
このDIとAOPという2つのフレームワークによって、オブジェクトを「生成」して「利用」し「消滅」されるまでをサポートしているため、オブジェクトフレームワークと呼ばれます。

Ray.Di

発表では少しだけDIの使い方を紹介しました。これは、DIの使い方を紹介したかった、というよりは、使い方からRay.Diの持っている価値観を見た方が理解しやすいのではないか、と思ったからです。

Symfony DI and Ray.Di Pattern A

最初に比較のために、SymfonyのDIコンポーネントと、それと似た形でのRay.Di（Ray.Di Pattern Aスライド）でのDIの使用方法を紹介しました。

この方法では、対象に全く触らずに依存関係を構築でき、依存関係はインジェクター側で全て持っている点も特徴です。

また、Ray.Diの場合、親クラスを指定した場合でも、その設定が継承され注入されます。（例ではMailerクラス自体ではなく、そのベースクラスであるMailerBaseクラスへDIしています）

ですが、BEARにおいては、この方法でのDIは特別な場合を除いて推奨されません。 BEAR.Sundayの標準の方法はアノテーションを使った方法です。

Ray.Di Pattern B (BEAR.Sunday standard, DI with annotation)

アノテーションを使ったDIでは文字通り、注記（＝アノテーション）になりコードの読みやすさが向上されます。
SymfonyのDIコンポーネントや、Pattern Aで紹介した方法と比べて、NewsletterManager に対するDIの設定が行われていないのが分かるでしょうか。

これにより、「同じ依存が欲しいときにはモジュールに設定を追加する必要がなく、注入が欲しい箇所にアノテーション（@Inject）を加えるだけで済む」という特徴があります。

言い方を変えれば、この方法では“どの依存を用意するか”に注目し、依存中心に考えていることになります。（もちろん、どちらが良いという話ではなく、BEAR.Sundayではそのような価値観を持って作られている、ということです）

モジュール

モジュールでは、複数のモジュールを合成することで、DIやAopの知識を構成します。
Ray.Diでは、そのモジュールの持つ知識を持ってオブジェクトグラフを構築することになります。

オブジェクトグラフとは、下記のようなイメージです。

(Object Framework - Ray.Di | BEAR blog より)

この図では、Controllerが各ModelやEvent、Session、ACL、Viewなどの注入を必要としています。
また、SessionnではStrageの注入が、ViewではFromやTemplateの注入を必要としています。

このように、依存関係をDIによって再帰的に解決していき、必要なオブジェクトのすべてがDIによって注入されることになります。

（追記）記事公開時の説明に間違いがありましたので修正を行いました。間違っていた個所は以下の記述です。

また、LogやConfigは複数のオブジェクトによって必要とされています。これは、特定のオブジェクトに依存するものではなく、複数のオブジェクトに渡って必要な、つまり横断的関心事（アスペクト）です。この横断的関心事はAOPフレームワークであるRay.Aopを使って解決することになります。

複数のオブジェクトに同じオブジェクトが必要な場合の注入（早期束縛）は、DIで行われます。

AOPを利用するのは、横断的関心事（アスペクト）を解決したい場合です。たとえば、ロギングしたい、とか、アクセス･コントロールしたい、とかを実現するために、Ray.Aopを使って振る舞いを変更します。

また、動的に利用するオブジェクトを変更したい場合（遅延束縛）、例えば、Select時はslave DBを使い、Insert時はmaster DBと使うようにする、とか、指定されたIDによってSelect/InsertするDBを変更したい、のような（動的に）依存を解決したい場合は、Ray.Aopによるランタイムインジェクションによって動的に必要なオブジェクトをインジェクトすることができます。（Object Framework - Ray.Aopの「ランタイムインジェクター」節を参照）

LogやConfigは複数のオブジェクトによって必要とされていますが、Ray.Diではそのオブジェクトが必要なクラスに、LogInterfaceやConfigInterfaceを受け取るコンストラクタ、もしくは、セッターを用意し「@Inject」アノテーションを加えるだけで、すべてのLog、Configが必要なクラスにそれぞれのオブジェクトをDIできます。

これは、Ray.DIが（アノテーションでの指定であれば）それぞれの（注入される側の）オブジェクトに対してDIを行うのではなく、インターフェース（もしくは名前）に基づいてDIを行うためで、モジュール側で一度、LogInterfaceに対してLogオブジェクトを注入するという指定を行えば、すべてのLogInterfaceが必要な個所にLogオブジェクトが注入されるためです。

（同じインターフェースに対して別々のオブジェクトの注入を行いたい場合、名前付き（@Named）で指定することで行えます）

Ray.Aop

AOPではインターセプタによって処理の前後に任意の処理を織り込むことができ、これによりオブジェクトのメソッドの利用にこれまでにない拡張性と機能性を与えます。
ここで注目したいのは下記に説明する2点です。（スライドのサンプルコードを参照）

1つめは、利用側（$user->save()）のコードを変更しなくても、インターセプタが適用されるということ。つまり、getInstance した際には、Weaverされたインターセプタが織り込み済みのオブジェクトが返ってきているから。

2つめは、メソッドが呼び出す側（この例の場合、TimerIntercepter）は、$invocation->proceed()のコールによりオリジナルメソッドを実行しているつもりだけど、本当にオリジナルメソッドが呼ばれているかどうかはわからない、ということ。
つまり、インターセプタをチェーンすることで、メソッド実行がチェーンされるため、インターセプタ同士はどの位置のインターセプタかも知らないけど、最後のインターセプタだけが実際のメソッドを呼び出し、それ以外のメソッドは（オリジナルのメソッドを呼び出しているつもりで）次のインターセプタを呼び出している。
言い方を変えると、インターセプタによってアスペクトが織り込まれている、ということ。

サンプルコード内の利用部分で、Ray\Di\Injector::create([new DevModule]);というコードがありますが、これは、DevModuleではなくUserModuleの間違いです。

AOPを実現するのに裏で複雑な処理が行われているように思うかもしれませんが、実際に、Ray.Aopでのインターセプタの実装を見ると基本的なコードはこれだけです。（スライド: インターセプタのRay.Aop実装を参照）
インターセプタが空＝残っていなければオリジナルメソッドを呼び、次のインターセプタがあれば、自分を引数としてinvokeメソッドを呼び出しているだけ。

たったこれだけで、インターセプタが実現されていることはちょっと驚きじゃないかと私はそう感じました。

まとめ

Ray では、オブジェクトを生成する（コンパイル）ための Ray.Di と、それを利用（ランタイム）するための Ray.Aop の2つを組み合わせることで、生成と利用を分離する、ひいては関心の分離を強力にサポートします。

また、生成と利用がはっきりと分離されていることにより、生成（コンパイル）されたオブジェクトグラフをそのまま再利用することができるようになります。
生成が再利用できることで、すべてのオブジェクトをキャッシュすることが可能で、パースやインジェクションのコストを原理的には0にすることが可能です。

説明した内容は Ray のもつ一部のコンセプトや機能ですが、興味を持ったら、是非使ってみてください！

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻其の参

2012-07-12T22:07:00+09:00

こんにちは。呼ばれて飛び出てジャジャジャジャーン、@madapajaです。

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻シリーズ

続きです。前回は、Ray.Di を使って依存性の注入を行ってみました。今回は、Ray.Aop でインターセプターを使い、アスペクト指向プログラミングの体験を中心に進めてみたいと思います。

前回の補足

…と、その前に前回の補足を。

`@PostConstruct` アノテーション

前回、@PostConstruct アノテーションによって初期化メソッド（__construct() 後に実行するメソッド）の定義を行いました。
これはコンストラクタでやるのと、何が違うのでしょうか？今回のサンプルの場合、コンストラクタ上で呼び出しても挙動は変わりません。
なぜコンストラクタで行わないのか、その理由を3つほど考えてみました。（@koriymさんからもアドバイスをもらいました）

1つめは、関心を分離させるためです。
コンストラクタでは文字通り構造を構成する（つまり、プロパティへの代入）のみに徹し、@PostConstruct 内でその構成されたオブジェクトに対しての初期化処理を記述することで関心を分離させられます。

2つめは、@PostConstruct では全ての依存が注入されているのが保証されています。
前回のサンプルではコンストラクタへのインジェクションを行いましたが、Ray.Di ではSetterを使ったインジェクションも可能です。コンストラクタでも、Setterでも注入するという点では同じですし、挙動も基本的に変わりませんが、Setterインジェクションを行うことで、traitを利用しやすくなります。（実際に、BEAR.Sundayではtraitを利用して、テンプレートエンジンを注入したり、様々な箇所で使用されています。）
Ray.Diの内部の挙動は、コンストラクタへの注入後に、Setterへの注入が行われ、最後に @PostConstract が呼ばれます。
たとえば、複数のSetterインジェクションがあるような場合、それらの複合的な設定を行うには、全ての注入が保証されている @PostConstruct 内でしか初期化できない処理も考えられるでしょう。

3つめは、これは副次的な特徴ですが @PostConstruct では、同時にインターセプタを利用することが可能です。（逆に言えば、コンストラクタ内から別メソッド呼び出してもインターセプトされません。）
Ray.Di で、Injector::getInstance() を行うと、そのクラスの依存が解決した後に、依存を注入しオブジェクトを構成させ、その後にウィーバー（インターセプトを織り込む）され、最後に @PostConstruct が呼び出されます。
そのため、このアノテーション内では同時にインターセプトを利用することもできる、というわけです。

モジュールの作り方について

モジュールの分割単位は１）機能の関心ごと２）動作モード　などで分割します。sandboxアプリではDevModule（動作モード）がフレームワークモジュール、機能のモジュール、アプリケーションモジュール等をinstallしてます。
— BEAR.Sundayさん (@BEARSunday) 7月 12, 2012

機能はたとえばDbなら Database\PdoModule にするのか Database\DoctrineOrm にするのかといった具合です。そのモジュール内では必要なDI、AOP設定を行います。
— BEAR.Sundayさん (@BEARSunday) 7月 12, 2012

とあるように、モジュールは関心ごとに分離すべきです。（今回はサンプルなので…）

Ray.Diには、あるモジュールの中から他のモジュールをインストール（追加設定のような感じ）する機能があります。
機能・関心ごとにモジュールを分離させることで、たとえば、実行（本番、テスト、開発）モードが要求する機能や関心を、必要に応じて構成させることができるようになります。

これは、下のつぶやきにもあるように、BEAR.Sundayの大きな特徴の一つです。

ここが他のFWのイベントによる機能拡張と違うところで、FW内のコードでイベント（シグナル）を発行してApp側でコールバックをアタッチするのではなくて、サービスコンポーネントそのものをDIで入れ替え、その振る舞いをAOPで変更します
— BEAR.Sundayさん (@BEARSunday) 7月 12, 2012

すべてのメソッドにインターセプタをバインドしてみる

では、ようやく本編です。

処理時間を計るタイマーインターセプタを作り、それをすべてのメソッドへ問答無用で追加（バインド）してみたいと思います。メソッドへ適用するインターセプタは Ray\Aop\MethodInterceptor を継承して作ります。

メソッドが呼び出されると、invoke() が呼び出されるのでその中で前後に挟み込みたい処理を記述します。
今回は以下のように作りました。

src/Madapaja/Ray/Di/Sample01/Interceptor/Timer.php


namespace Madapaja\Ray\Di\Sample01\Interceptor;

use Ray\Aop\MethodInterceptor;
use Ray\Aop\MethodInvocation;

class Timer implements MethodInterceptor
{
    public function invoke(MethodInvocation $invocation)
    {
        printf('%s::%s(): Timer start'."\n", $invocation->getMethod()->class, $invocation->getMethod()->name);
        $mtime = microtime(true);
        $return = $invocation->proceed();
        $time = microtime(true) - $mtime;
        printf('%s::%s(): Timer stop [%01.7f sec]'."\n\n", $invocation->getMethod()->class, $invocation->getMethod()->name, $time);

        return $return;
    }
}

処理としては、メソッド開始前後にメソッド名とタイマー状況のアウトプットと、計測処理を行っているだけですね。

invoke メソッドは呼び出される際に引数としてメソッド実行に必要な知識を持ったオブジェクト（MethodInvocation）が渡されます。
その知識を利用してメソッド名などを表示させ、また、14行目で $invocation->proceed() することでオリジナルのメソッドを実行します。

さあ、インターセプタが出来たのでそれをバインドします。

前回説明したとおり、アプリケーションやフレームワークを構成する際に使われる知識はモジュールが持ちます。
UserModule にインターセプタをバインドする処理を追加します。

src/Madapaja/Ray/Di/Sample01/Module/UserModule.php


namespace Madapaja\Ray\Di\Sample01\Module;

use Ray\Di\AbstractModule;
use Madapaja\Ray\Di\Sample01\Interceptor\Timer;

class UserModule extends AbstractModule
{
    protected function configure()
    {
        // bind dependency @Inject @Named("pdo_user")
        $pdo = new \PDO('sqlite::memory:', null, null);
        $this->bind('PDO')->annotatedWith('pdo_user')->toInstance($pdo);

        // bind aspect Timer
        $this->bindInterceptor(
            $this->matcher->any(),
            $this->matcher->any(),
            [new Timer]
        );

    }
}

17行目から bindInterceptor メソッドでインターセプタをバインドしています。このメソッドは 3 つの引数を取り、1つ目はクラスのマッチャーを、2つめはメソッドのマッチャーを、3つめはインターセプターの配列を渡します。
1つめと、2つめの引数に $this->matcher->any() を渡すことで、すべてのメソッドに適用されるようになります。

この状態で、php main.php として実行してみると、タイマーインターセプタがバインドされていることが分かるかと思います。

Madapaja\Ray\Di\Sample01\Model\User::init(): Timer start
Madapaja\Ray\Di\Sample01\Model\User::init(): Timer stop [0.0005341 sec]

Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer start
Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer stop [0.0001001 sec]

Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer start
    :
    :

アノテーションを使って特定のメソッドにインターセプタをバインドしてみる

次に、トランザクションを行うインターセプタを作って特定のメソッドへのバインドをしてみます。特定のメソッドへのバインドは、メソッド名のプレフィックスやアノテーションでマッチさせることができますが、今回は汎用的に使えるようにアノテーションでマッチさせるようにします。

まずはタイマーの時と同じように、トランザクションインターセプタを作ります。

src/Madapaja/Ray/Di/Sample01/Interceptor/Transaction.php


namespace Madapaja\Ray\Di\Sample01\Interceptor;

use Ray\Aop\MethodInterceptor;
use Ray\Aop\MethodInvocation;

/**
 * Transaction interceptor
 */
class Transaction implements MethodInterceptor
{
    public function invoke(MethodInvocation $invocation)
    {
        $object = $invocation->getThis();
        $ref = new \ReflectionProperty($object, 'db');
        $ref->setAccessible(true);
        $db = $ref->getValue($object);
        $db->beginTransaction();
        try {
            echo "begin Transaction" . json_encode($invocation->getArguments()) . "\n";
            $invocation->proceed();
            $db->commit();
            echo "commit\n";
        } catch (\Exception $e) {
            $db->roleback();
        }
    }
}

15行目で $invocation->getThis() し、実行されるオブジェクト（User オブジェクト）を取得しています。トランザクションを行うために User::$db へのアクセスを行いたいのですが、このプロパティはプライベートプロパティのため、そのままアクセスすることができません。

そこで 16行目でリフレクションプロパティを取得し、プロパティをアクセス可能にした上でトランザクション処理を行っています。

次に、このインターセプタを適用させるアノテーションを作ります。
今回は @Transactional アノテーションという名前で以下のように作りました。

src/Madapaja/Ray/Di/Sample01/Annotation/Transactional.php


namespace Madapaja\Ray\Di\Sample01\Annotation;

use Ray\Di\Di\Annotation;

/**
 * @Annotation
 * @Target("METHOD")
 */
final class Transactional implements Annotation
{
}

作ったアノテーションを User クラスに適用させましょう。

src/Madapaja/Ray/Di/Sample01/Model/User.php


namespace Madapaja\Ray\Di\Sample01\Model;

use Ray\Di\Di\Inject;
use Ray\Di\Di\Named;
use Ray\Di\Di\PostConstruct;
use Madapaja\Ray\Di\Sample01\Annotation\Transactional;

class User
{
    // ...

    /**
     * @Transactional
     */
    public function createUser($name, $age)
    {
        $sth = $this->db->prepare('INSERT INTO User (Name, Age) VALUES (:name, :age)');
        return $sth->execute(array(':name' => $name, ':age' => $age));
    }

    // ...

use してアノテーションするだけです。

最後に UserModule でバインドします。

src/Madapaja/Ray/Di/Sample01/Module/UserModule.php


namespace Madapaja\Ray\Di\Sample01\Module;
use Madapaja\Ray\Di\Sample01\Interceptor\Timer;
use Madapaja\Ray\Di\Sample01\Interceptor\Transaction;

use Ray\Di\AbstractModule;

class UserModule extends AbstractModule
{
    protected function configure()
    {
        // ...

        // bind aspect @Transactional method
        $this->bindInterceptor(
            $this->matcher->any(),
            $this->matcher->annotatedWith('Madapaja\Ray\Di\Sample01\Annotation\Transactional'),
            [new Transaction]
        );
    }
}

18行目で、メソッドに @Transactional アノテーションが指定されている場合にマッチするように、annotatedWith() マッチャーを使ってバインドします。

これでトランザクションインターセプタがバインドできましたので、php main.php として実行してみましょう。

Madapaja\Ray\Di\Sample01\Model\User::init(): Timer start
Madapaja\Ray\Di\Sample01\Model\User::init(): Timer stop [0.0005541 sec]

Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer start
begin Transaction["Koriym",30]
commit
Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer stop [0.0001891 sec]

Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer start
begin Transaction["Bear",22]
commit
Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer stop [0.0001378 sec]

Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer start
begin Transaction["Yoshi",25]
commit
Madapaja\Ray\Di\Sample01\Model\User::createUser(): Timer stop [0.0001421 sec]

Madapaja\Ray\Di\Sample01\Model\User::readUsers(): Timer start
Madapaja\Ray\Di\Sample01\Model\User::readUsers(): Timer stop [0.0000980 sec]
    :
    :

このように @Transactional アノテーションをした User::createUser() メソッドのみにトランザクションが行われているのが分かるかと思います。

とりあえず、サンプルを通じて Ray の触りをご紹介できたと思います。

インターセプター面白いです。

参考リンク

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻シリーズ

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻其の弐

2012-07-11T20:07:00+09:00

こんにちは。夏はやっぱり生ビール、@madapajaです。
PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻其の壱 : 今日も適当ダイアリーの続きです。

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻シリーズ

前回は、Ray を Composer 経由でインストールして User クラスを作りました。

Ray を使わずに書いてみる

Ray を使ってみる前に、普通に PHP を書いて User クラスを実行してみたいと思います。今回は Madapaja\Ray\Di\Sample01\App クラスを下記のように書きました。

src/Madapaja/Ray/Di/Sample01/App.php


namespace Madapaja\Ray\Di\Sample01;
use Madapaja\Ray\Di\Sample01\Model\User;

class App
{
    public function run()
    {
        $pdo = new \PDO('sqlite::memory:', null, null);
        $user = new User($pdo);

        $user->init();

        $user->createUser('Koriym', mt_rand(18,35));
        $user->createUser('Bear', mt_rand(18,35));
        $user->createUser('Yoshi', mt_rand(18,35));

        $users = $user->readUsers();
        print_r($users);
    }
}

そして上の App クラスを実行するために下記のファイルを作ります。内容はオートローダを読み込んで App::run() を実行するだけです。

main.php


require __DIR__.'/vendor/autoload.php';

use Madapaja\Ray\Di\Sample01\App;
(new App())->run();

ここまで出来たら php main.php として実行してみます。

Array
(
    [0] => Array
        (
            [Name] => Koriym
            [Age] => 24
        )

    [1] => Array
        (
            [Name] => Bear
            [Age] => 18
        )

    [2] => Array
        (
            [Name] => Yoshi
            [Age] => 30
        )

)

のように、結果が表示されたでしょうか？簡単ですね。というか、普通のPHPなので当たり前ですね。

Ray.Di でインジェクトしてみよう

やっと、Rayの出番です。Ray.Diを使って依存性を注入してみます。今回の場合は、 User クラスへ PDO を注入します。

Ray では DI や AOP の設定をモジュールという単位（クラス）で行います。モジュールはアプリケーションやフレームワークを構成する際に使われる知識を持っており、その知識をもとにインジェクターが依存を注入することで、適切なオブジェクトグラフを生成されることになります。
とりあえず、モジュールで DI と AOP の設定をするよ、ということが分かればOKです。

アノテーションの追加

モジュールを作る前に、User クラスのコンストラクタへインジェクトを行うことを示すために、アノテーションを追加します。

src/Madapaja/Ray/Di/Sample01/Model/User.php


namespace Madapaja\Ray\Di\Sample01\Model;

use Ray\Di\Di\Inject;
use Ray\Di\Di\Named;

class User
{
    private $db;

    /**
     * @Inject
     * @Named("pdo=pdo_user")
     */
    public function __construct(\PDO $pdo)
    {
        $this->db = $pdo;
    }

    // ...

13行目で @Inject アノテーションによってインジェクトポイントだということを示し、14行目で @Named アノテーションで pdo_user という名前で（pdo を）バインドすることを示します。
なお、5～6行目は @Inject と @Named アノテーションの名前空間を解決させるために use しています。

UserModule を作る

ということで、User クラスの構成設定を行う UserModule を作ります。モジュールは Ray\Di\AbstractModule を継承し configure() メソッド内で構成の設定を行います。

src/Madapaja/Ray/Di/Sample01/Module/UserModule.php


namespace Madapaja\Ray\Di\Sample01\Module;

use Ray\Di\AbstractModule;

class UserModule extends AbstractModule
{
    protected function configure()
    {
        // bind dependency @Inject @Named("pdo_user")
        $pdo = new \PDO('sqlite::memory:', null, null);
        $this->bind('PDO')->annotatedWith('pdo_user')->toInstance($pdo);
    }
}

DI の設定は 13 行目で行っており、PDO クラスの pdo_user という名前の箇所に PDO インスタンス（$pdo）をバインドしています。（本来はインターフェースではない PDO クラスや、その実体（インスタンス）を使用しない方がいいのですが、ここではコードを簡単にするために許してもらいます。）

インジェクタ経由でインスタンスを取得する

これで準備が整いました。 App クラスを書き変えてインジェクタを利用してみます。

src/Madapaja/Ray/Di/Sample01/App.php


namespace Madapaja\Ray\Di\Sample01;

use Ray\Di\Injector;
use Madapaja\Ray\Di\Sample01\Module\UserModule;

class App
{
    public function run()
    {
        $di = Injector::create([new UserModule]);
        $user = $di->getInstance('Madapaja\Ray\Di\Sample01\Model\User');

        $user->init();

        // ...

12行目で、今作った UserModule を指定してインジェクタを生成し、13行目で実際に User クラスのインスタンスを取得しています。これで、依存がよしなに解決されるようになりました。

アノテーションのオートロードを設定

さっそく実行してみたいところですが、アノテーションのオートロードのためにもうひとつ処理を追加する必要があります。これは BEAR.Sunday ではフレームワーク側でやってくれますので、今回のように Ray をスタンドアロンで利用する場合にのみ必要な設定です。

main.php でオートローダーを取得して、アノテーションレジストリにローダーを登録します。実際のソースは下記のようになります。

main.php


use Doctrine\Common\Annotations\AnnotationRegistry;
use Madapaja\Ray\Di\Sample01\App;

$loader = require __DIR__.'/vendor/autoload.php';
AnnotationRegistry::registerLoader(array($loader, "loadClass"));

(new App())->run();

これでやっと実行できるようになりました。php main.php を実行させて問題なく動くのを確認してみましょう。

@PostConstruct アノテーションによる初期化メソッドの定義

これまでUser クラスを初期化するために、 App クラスで User::init() メソッドを呼び出していました。これを @PostConstruct アノテーションすることで、インジェクタに初期化メソッドの呼び出しを任せようと思います。

src/Madapaja/Ray/Di/Sample01/App.php


// ...

class App
{
    public function run()
    {
        $di = Injector::create([new UserModule]);
        $user = $di->getInstance('Madapaja\Ray\Di\Sample01\Model\User');

        // $user->init();

        // ...

App.phpの修正は、12行目を削除するだけです。
次に User クラスにアノテーションを追加します。

src/Madapaja/Ray/Di/Sample01/Model/User.php


namespace Madapaja\Ray\Di\Sample01\Model;

use Ray\Di\Di\Inject;
use Ray\Di\Di\Named;
use Ray\Di\Di\PostConstruct;

class User
{

    // ...

    /**
     * @PostConstruct
     */
    public function init()
    {
        return $this->db->query('CREATE TABLE User (Id INTEGER PRIMARY KEY, Name TEXT, Age INTEGER)');
    }

    // ...

名前空間を use して、@PostConstruct アノテーションを追加するだけです。これだけで、インジェクタの getInstance メソッドでインスタンスを取得する際、コンストラクタ後にアノテーションしたメソッドが呼び出されるようになります。

いよいよ Ray.Aop の登板！

という所なのですが、またもや長くなってきた（というか疲れた）ので、其の参に続きます！にんにん！

（7/12追記）続き書きました！

参考リンク

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻シリーズ

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻其の壱

2012-07-11T00:07:00+09:00

こんばんは。そろそろ健康診断なのでダイエットしようかと思ってる@madapajaです。

特にSymfony界隈などで話題になっている、PHP5.4+向けに開発が行われているリソース指向フレームワークBEAR.Sundayは皆さんチェックされてますか？

このフレームワークはPHP5.2+向けのリソース指向フレームワークBEAR.Saturdayの新バージョンにあたるもので、設計の全てを見直して@koriym氏によって開発が進められています。

リソース指向や、開発思想などについてはとってもここでは書き切れないので BEAR Blogなどをチェックしていただければと。

さて、そんなBEAR.Sundayですが、まだ開発中のフレームワークですので実際に使う上で足りない機能もたくさんありますし、アプリケーションコントローラなども機能追加や仕様変更がこれからたくさん行われることになるようです。

だけど、Bear.Sunday Meetup #0 が開催されるようだという情報も出回ってるいるので、さわりだけでも触ってみたい！

ということで、今後も仕様の変更はほとんど考えられない Ray.Di と Ray.Aopを使ってみよう、という企画です。

Rayって何?

Rayは、Google GuiceというJavaフレームワークのPHP版で、BEAR.Sundayと同じく@koriym氏によって開発されています。

Rayは2つのパッケージ、一つはDI（Dependency Injection）を行うためのRay.Di、もう一つはアスペクトを構成するためのフレームワークRay.Aopから構成されています。

今回はRay.Aopにあるサンプルを元にRayでどのようにアプリケーションを構成できるのかを見ていきたいと思います。

なお、今回のサンプルの完成版は下記においてありますので参考にどうぞ。

madapaja/ray-di-sample - Github

なお、このチュートリアル（？）ではGit、PHP5.4、PDO SQLite拡張が必要です。

RayをComposerでインストール

Ray/DiとRay/Aopをrequireに指定してcomposer install すればOK？と思ったのですが、そうは問屋が卸してくれませんでした。

試行錯誤の結果、下記の内容でインストールできたので実際にやってみる方はコピペするのが吉かと。

ついでに、自分の書くソースのautoload設定も追加しておきます。
私は名前空間は"Madapaja\Ray\Di\Sample01"としてsrcディレクトリ配下に置くことにしました。

composer.json


{
    "require": {
        "php": ">=5.4.0",
        "ext-pdo": "*",
        "ext-pdo_sqlite": "*",
        "Ray/Di": ">=1.0.x-dev",
        "doctrine/common": "2.3.x-dev",
        "Ray/Aop": ">=1.0.x-dev",
        "Aura/Di": ">=1.0.x-dev"
    },
    "autoload": {
        "psr-0": {
            "Aura\\Di": "vendor/Aura/Di/src/",
            "Madapaja\\Ray\\Di\\Sample01": "src"
        }
    }
}

上記ファイルが出来たら


curl -s http://getcomposer.org/installer | php
php composer.phar install

として、ライブラリをインストールしましょう。
実行して、ずらずらーっと文字が出てきて最後に「Generating autoload files」と表示されればOK。

では、実際にソースを書き始めます。

書き始める

さっそく、Rayを使いたいところですが、ぐっと我慢して普通のアプリケーションの開発と同じくモデルを書くところから始めます。

Userクラスを下記のように作りました。

src/Madapaja/Ray/Di/Sample01/Model/User.php



namespace Madapaja\Ray\Di\Sample01\Model;

class User
{
    private $db;

    public function __construct(\PDO $pdo)
    {
        $this->db = $pdo;
    }

    public function init()
    {
        return $this->db->query('CREATE TABLE User (Id INTEGER PRIMARY KEY, Name TEXT, Age INTEGER)');
    }

    public function createUser($name, $age)
    {
        $sth = $this->db->prepare('INSERT INTO User (Name, Age) VALUES (:name, :age)');
        return $sth->execute(array(':name' => $name, ':age' => $age));
    }

    public function readUsers()
    {
        $sth = $this->db->query('SELECT Name, Age FROM User');
        $result = $sth->fetchAll(\PDO::FETCH_ASSOC);
        return $result;
    }
}

なんてことはないDBのUserテーブルを操作する普通のクラス（Model）です。強いて言えば、依存関係は自分で解決せずに、DIによって後で良きに計らってもらえるように、コンストラクタでPDOインスタンスを受け取る形にしたくらいです。

もちろんこの段階でこのクラスに対してテストを書くのも簡単ですね。今回はこんな感じで書いてみました。

ここからRayの出番です

という所なのですが、予想以上に長くなってきた（というか疲れた）ので、其の弐に続きます！

実際のRayを触るのは次回になってしまいましたが、待ちきれないぜ、俺は今やりたいんだよ、という方はmadapaja/ray-di-sample のコミット履歴なんかが参考になるかもしれません。

（7/11追記）其の弐書きました！

参考リンク

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻シリーズ

Symfony勉強会 #6 に参加してきた〜Symfony温泉に向けて

2012-07-08T19:07:00+09:00

こんにちは。随分ブログをサボっていた @madapaja です。

先週、6/30に開かれたSymfony勉強会 #6 にスタッフとして参加しました。
なんと、勉強会＋懇親会で13時間に及んだ勉強会でしたが、やっぱりSymfony勉強会ってイイね、と思いました。

勉強会の内容や雰囲気については、ユーザー会や参加者の方の素敵なレポートを下の方にリンクしておくので、そちらを確認していただければと思いますが、何がイイって、Symfonyの話がそんなに無いのがイイねと。
そう言うとちょっと語弊があるかもしれないですけど、でも実際に、今回の勉強会ではSymfonyのHow toやコードや、実際に使う上での細かい（固有の）話は出てこなかったと思います。（ワークショップは除いて）
Symfonyを使う時にだけしか使えない、ひいて言えば、PHPを使う時だけにしか使えないような知識は登場せず、もっとその奥にある普遍的な知識が増やせる、そんな貴重な勉強会だったと思います。

また、もちろんSymfony以外のフレームワークの話や、オブジェクト指向ってみんな言ってるけど、その本質って何だっけ？とかいう話まで聞けちゃうというとってもお得な勉強会。
今回参加できなかった方は、機会があれば次回以降に是非！
そして、勉強会本編には参加したけど、懇親会は参加できなかった、という方は次は絶対に懇親会も参加してみてくださいね。
Symfony勉強会の懇親会は本編に増して素敵な話を聞けますよ。

ということで、Symfony勉強会に参加して、もっと勉強しなきゃなと思っている今日この頃です。

会場を提供していただいたVoyage Groupさん、ありがとうございました。そして、スピーカーの皆さん、参加者の皆さん、スタッフの皆さん、本当にお疲れ様でした！

Symfony温泉？

さて、Symfonyユーザー会では、過去何度か温泉旅行に行っています。
これは、Symfonyドキュメント周りの翻訳を一気に進めるために、有志で温泉に行って泊まりがけでドキュメントを翻訳しようぜ、というものなのですが、今年もSymfony勉強会で「Symfony温泉まだ？」という話も出始めているので、きっとSymfonyのイケメンさんが計画してくれるはず。

ということで、Symfonyコンポーネントの勉強も兼ねてちょっとしたツール（Symfony2ドキュメントの翻訳差分をチェックするツール）を作ってみました。

https://github.com/madapaja/prompter

Symfony2の日本語のドキュメントは、オリジナルのドキュメント更新と付き合わせられるように、そのコメント内にコミットハッシュを書いてあります。なので差分を翻訳する際には、そこに記載されているコミットハッシュとオリジナルドキュメントのHEADのdiffをとって云々……という事をしないといけないのですが、いかんせんそれが面倒なので、ちゃちゃっとコマンドを作りました。

./prompter/prompter check ./symfony-docs ./symfony-docs-ja

などという風に、オリジナルと日本語のドキュメントのルートを渡すと、各ファイルの翻訳状況がずらーっと表示されます。（画像の白が翻訳されているもの、黄色が更新されているもの、青が不明なもの、赤が一方のファイルがないもの）

./prompter/prompter check ./symfony-docs/book/controller.rst ./symfony-docs-ja/book/controller.rst

のようにファイル名まで指定すれば、そのファイルの詳細な状態を確認する事も出来ます。

使用した Symfonyコンポーネントは、Consoleコンポーネント、Finderコンポーネント、Processコンポーネントの3つ。
見た目にも綺麗なコンソールアプリを作るためにConsoleコンポーネントを、ディレクトリ内のファイルの操作にFinderコンポーネントを、Gitコマンドをサブプロセスとして簡単に実行するためにProcessコンポーネントを使ってみました。

Symfonyコンポーネントは単体で簡単に利用できることは知っていたものの、実際にこういう形で使ったことが無かったのですが、とても簡単に利用出来ました。

本当はコンポーネントの使い方を…と思ったのですが、長くなりそうなので別の機会に紹介したいと思います。

勉強会レポート

Symfony勉強会 #6 のレポートをリンクしておきます。漏れなどありましたら、教えてください！

選択範囲のテキストを操作する jQuery.selection を更新して github に移行しました

2012-05-09T07:05:00+09:00

昔作った、選択範囲のテキストを操作するための jQuery プラグイン jQuery.selection が長らく放置されていたのですが、使っていただいている方もいるようなので、メンテナンスして github にあげました。

メンテナンスの過程で、メソッド名を大幅に変更してしまいましたが。。。

jQuery.selection とは

選択範囲のテキストを操作するための jQuery プラグインです。
テキスト選択（キャレット）位置や、選択テキストを取得したり、選択されているテキストの置き換えや挿入などを行えます。

詳細は紹介ページ内のデモをご覧ください。

変更点

IE でテキストボックスの選択範囲（キャレット情報）を取れない問題を修正
メソッド名などを大幅に変更
QUnit のテストを追加

リンク

ということで、バグなどあれば issue を挙げていただくか、コードを直して pull request ください！
よろしくお願いします。

PHP5.4 で Symfony2 は速くなるのか？

2011-12-07T00:12:00+09:00

Symfony Advent Calendar JP 2011 7日目です。
6日は @uechoco さんによる [Symfony2]入出力の文字エンコードを変換してみよう Symfony Advent Calender JP 2011 – 6日目- でした。

さて、@uechoco さんから「MongoDB JPにも所属している@madapajaさん」と紹介いただき、これは MongoDB ネタをやれってことかな？とか考えてしまいましたが、今回は PHP5.4 がらみのことを。

PHP5.4 は速くなっているらしいと風の噂で聞いたものの、Symfony2 は速くなるのかなと思ったので試してみました。
環境によって結果が異なると思いますが、今回は Symfony2 本体のテスト速度を計測してみます。
今回テストに用いた環境は下記の通りです。

サーバー	さくらのVPS 512
OS	Ubuntu 10.04.3 LTS
PHP	5.3.8 5.3.9 RC2 5.4.0 RC2

PHP はすべて下記のconfigureオプションを用いてコンパイルしました。


  --with-openssl \
  --with-pcre-regex \
  --with-zlib \
  --with-mhash \
  --with-xsl \
  --enable-intl \
  --enable-mbstring \
  --with-mcrypt \
  --enable-pcntl \
  --with-libedit \
  --with-readline \
  --with-pear \
  --disable-debug

PHPUnit をインストール。


$ ./php-5.X/bin/pear channel-discover pear.phpunit.de
$ ./php-5.X/bin/pear channel-discover components.ez.no
$ ./php-5.X/bin/pear channel-discover pear.symfony-project.com
$ ./php-5.X/bin/pear install phpunit/PHPUnit

最後に最低限の php.ini を設定します。


extension=apc.so

short_open_tag = Off
magic_quotes_gpc = Off

[Date]
date.timezone = Asia/Tokyo

念のためバージョンを確認。


$ ./php-5.3.8/bin/php -v
PHP 5.3.8 (cli) (built: Dec  3 2011 16:37:19)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

$ ./php-5.3.9RC2/bin/php -v
PHP 5.3.9RC2 (cli) (built: Dec  3 2011 16:45:05)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

$ ./php-5.4.0RC2/bin/php -v
PHP 5.4.0RC2 (cli) (built: Dec  3 2011 16:55:22)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies

いざ、テスト！

テストは、symfony/symfony - GitHub から clone して、vendors.php でベンダーファイルをインストールしたら、phpunit と叩くだけです。
今回は、PHP 5.3.8 → 5.3.9RC2 → 5.4.0RC2 の順でテストを実行させ、それを11周実行することにしました。そのうちの、1サイクル目を除いた10サイクル分の結果を比較してみます。（なお、テスト間は 5秒の sleep を入れてあります。）

では実行結果です。じゃじゃーん。
PHPUnit で表示される秒数とメモリ（Mb）の平均です。

	Time (Sec.)	Memory (Mb)
PHP 5.3.8	19.6	264.0
PHP 5.3.9RC2	19.0	191.5
PHP 5.4.0RC2	14.2	136.8

結果は明白ですが、一応グラフも。数値が低い方がベターなのは言うまでもありません。

PHP 5.4.0 の方が時間、メモリ共に効率がよくなっているようです。PHP 5.3.8 と 5.3.9 の比較では時間はさほど変わりませんでしたが、メモリの使用量は減っていますね。
構成や設定など環境や使い方によって結果は異なってくるかと思いますが、PHP 5.4 のリリースも楽しみにしたいと思いました。

PHP 5.4.0RC2 で謎のセグフォ

PHP 5.4.0RC2 でテストを実行したら、テストの途中で Segmentation Fault で落ちるという事態が発生しました。
あーだこーだと悩んだ挙句に下記の変更で無理やり回避出来ることがわかりました。

// src/Symfony/Component/HttpKernel/Kernel.php
    :

    // 530行目あたり
    protected function initializeContainer()
    {
        $class = $this->getContainerClass();
        $cache = new ConfigCache($this->getCacheDir().'/'.$class.'.php', $this->debug);
        $fresh = true;
        if (!$cache->isFresh()) {
            $container = $this->buildContainer();
            $this->dumpContainer($cache, $container, $class, $this->getContainerBaseClass());

            $fresh = false;
        }

        usleep(0); ///< これを追加

        require_once $cache;
        $this->container = new $class();
        $this->container->set('kernel', $this);
    :

もちろんこれは根本的な解決ではなく、そして Symfony2 のバグでもなく、PHPか、そのモジュールか、環境によるバグだと思われます。
とりあえず、Symfony2 のバグでは無さそうだ、という事を確認しただけで調べていないのですが、とりあえず、私の環境では上記の行にシステムコール（というのが正しいのか分かりませんが、sleepとかfopenとか）があるとセグフォらない、という状況でした。

（追記）
この問題が発生したのは、SecurityBundle の機能テストのみです。（具体的には下記テストの実行でセグフォ）
src/Symfony/Bundle/SecurityBundle/Tests/Functional/FormLoginTest.php
src/Symfony/Bundle/SecurityBundle/Tests/Functional/LocalizedRoutesAsPathTest.php
src/Symfony/Bundle/SecurityBundle/Tests/Functional/SecurityRoutingIntegrationTest.php

さあ、明日の Symfony Advent Calendar JP 2011、第8話は @yuchimiri さんです！
お楽しみに！

PHP5.4+ で開発が行われている BEAR.Sunday フレームワークを動かしてみる

2011-12-06T01:12:00+09:00

PHP5.4 Advent Calendar 2011 6日目です。
5日は @chobi_e さんによる 5.4のSession周りの変更についてでした。

さて、勢いにまかせて Advent Calender に名乗り出たもののネタをどうしようか、と思っていたら、先日開催された Symfony 勉強会兼忘年会で @koriym 師匠に出会いいたく感銘を受けました。
そこで、@koriym さんが開発をされている BEAR.Sunday を動かしてみたいと思います。

BEAR はリソース指向の PHP フレームワークで、現行のバージョンは BEAR.Saturday というコードネーム（？）で開発されています。
その次期バージョンとして PHP 5.4+ で開発が行われているのが BEAR.Sunday です。

※下記は開発中のバージョンに対しての動作結果になりますので、下記のとおり行っても動かなかったり、今後構造が変更される可能性が高いです。

インストールは下記のコマンドで行えます。

$ git clone git://github.com/koriym/BEAR.Sunday.git
$ cd BEAR.Sunday

現在の最新は dev2 ブランチのようです。

$ git checkout -b dev2 origin/dev2
$ git submodule update --init

サンプルアプリケーションを動かすには下記のようにします。

$ php apps/01-helloworld/htdocs/index.php get /Hello 
[HEADER]X-Cache-Since: Tue, 06 Dec 2011 00:54:15 +0900 (15120)
[HEADER]X-Request-Per-Second: 0
[HEADER]X-Memory-Peak-Usage: 1,310,720
[BODY]

    Hello World

ビルトインウェブサーバー対応

ビルトインウェブサーバーにも対応予定で、開発やデバッグに活用できることになるかと思います。

実はここで実際に動かしてみようと思ったのですが、私の環境+取得したバージョンではうまく動きませんでした……。（devブランチ版では動いたのですが）

Trait によるページ単位でのテンプレートエンジン選択

（2012/07/13追記）
コメント欄で、開発者でもある @koriym 氏より指摘いただきましたが、この機能は現在（2012/07/13）、DIによる「テンプレートエンジンの注入」に変更されています。
以下は執筆当時の内容となりますのでご注意ください。

BEAR.Sunday の現在の実装では、Trait を用いてページ単位でテンプレートエンジンを変更することが可能です。

apps/02-template-engine/Page 配下に Page リソースがあり、4つのテンプレートエンジンの切り替えのサンプルが実装されています。
以下の2つのテンプレートエンジンの例を見れば分かる通りなのですが、基本的に変更されているのは、10行目の Trait の利用を指定する use 文のみです。
Trait によって、疎結合になり水平方向に展開されている（BEAR.Sunday の開発方針の一つとして「継承より合成を好む」と語られています）のが見て取れます。何をどうしているのか、が初めてこのコードを見ても直感的に分かる、というのも重要なポイントですね。
テンプレートエンジンに PHP を使ったページ

namespace template\Page;

use BEAR\Resource\Object as ResourceObject,
    BEAR\Resource\AbstractObject as Page,
    BEAR\Resource\Resource;

class Php extends Page
{
    use BEAR\Framework\Link\View\Php; ///<

    public function __construct()
    {
    }
    :

テンプレートエンジンに Twig を使ったページ

namespace template\Page;

use BEAR\Resource\Object as ResourceObject,
    BEAR\Resource\AbstractObject as Page,
    BEAR\Resource\Resource;

class Twig extends Page
{
    use BEAR\Framework\Link\View\Twig; ///<

    public function __construct()
    {
    }
    :

まもなくデビューする PHP5.4 と併せて PHP5.4+ なフレームワークも要注目です！

BEAR 自体を紹介することは出来ませんでしたが、非常に興味深いフレームワークであり、コードを読むと様々なチャレンジが凝縮されているのがよくわかります。
Symfony 勉強会でも、グローバル変数や、goto 文の使用などが注目されていましたが、開発"慣れ"している方にとっては、ハッと思わされるような事が多くあります。ただ、BEAR.Sunday では「敢えて」そのように書かれており、その背景には深い考察があります。

BEAR(Sunday) に興味を持った方は、下記ブログなどで設計思想や設計方針が語られていますので、是非そちらもチェックしてみてくださいね。

@koriym さんは「PHP はスクリプト言語です」とも投げかけていました。これについては、昨日 @BEARSunday でつぶやかれていましたので興味のある方はそちらも要チェックですよ。

さて、PHP5.4 Advent Calender 7日目は @Hiraku さんです！

2.0 からはじめる MongoDB - 第1回 #mongodbjp

2011-09-21T00:09:00+09:00

勉強会用の名刺が届いてウハウハ（？）な @madapaja です。

関連記事もどうぞ

2.0 からはじめる MongoDB
- 第0回 MongoDB の紹介
- 第1回インストール～シェルと戯れる
【番外編】MongoDB の歴史（MongoDB 2.0 まで）

この連載では MongoDB をこれからはじめる方に向けて、MongoDB 2.0 で追加された機能を含んだ、MongoDB 全体を広くご紹介していきたいと思っています。

今回のアジェンダ

なぜ MongoDB か
MongoDB のインストール
MongoDB シェルと戯れる

なぜ MongoDB か

MongoDB はここ1～2年で注目が高まった、NOSQL（Not Only SQL）と呼ばれる、“非”RDBMS（Relational DataBase Management System）なデータベースの一つです。
様々な所で議論されているように、NOSQL データベースは既存の RDBMS に完全に置き換わる存在ではなく、それぞれの長所・短所を理解した上で、RDBMS と NOSQL をうまく組み合わせることで、より柔軟でスケールしやすいシステムを作ることが可能でしょう。

さて、その NOSQL の中でも MongoDB が注目されている理由は、その「簡単さ」にあるでしょう。MongoDB にはインストール、運用、クエリ（問い合わせ）、インデックスなど様々な点でエンジニアが思ったことを実現する機能が充実しています。特にクエリやインデックスの機能については、柔軟で豊富なクエリと、どの属性に対してもインデックスを作成できるフル・インデックスのサポートにより、既存の RDBMS からの移行でも戸惑うことなく開発に専念させてくれます。

もう少し後押しするために、採用実績にも触れておこうと思います。
採用実績は、公式サイトの Production Deployments に掲載されていますので、その中からいくつかピックアップしてご紹介します。

Disney: インタラクティブメディアグループ内のすべてのゲームの共通のツールと API の、ステータス情報を保持するコモン・オブジェクト・リポジトリとして MongoDB が使われています。
foursquare: 位置ベースのソーシャルネットワークである foursquare は、場所と場所へのユーザー「チェックイン」を保持するために、MongoDB が使われています。
bit.ly: リンクの短縮、シェアとトラッキングを行える bit.ly では、MongoDB がユーザー履歴を保持するために使われています。
SourceForge: MongoDB が SourceForge の全プロジェクトのフロントページ、プロジェクトページ、ダウンロードページのバックエンドストレージとして使われています。
github: ソーシャルコーディングサイトの GitHub では、内部のリポーティングアプリケーションで MongoDB が使われています。
株式会社プリファードインフラストラクチャー: 株式会社プリファードインフラストラクチャーの、様々な検索ニーズに対応する“統合検索プラットフォーム”Sedue（セデュー）では、現在、MongoDB を使用して柔軟性、可用性の高い方法でドキュメントが保存されています。
CyberAgent, Inc.: CyberAgent, Inc. では、Ameba Pico（ピグの海外版）、Ameba tappie（タッピー）サービスにて MongoDB が使われています。

では、そろそろ実際に MongoDB を触れて、その世界を体験していただきたいと思います。
MongoDB が柔軟で、パワーがあり、スピードが出て、簡単に使えるように設計されている、ということを第0回から紹介してきたわけですが、その思想は至る所に現れています。
もちろんインストールやコンソールも例外ではありません。いかに簡単でパワフルかを触りながら実感して頂ければと思います。

MongoDB のインストール

MongoDB は様々なプラットフォームへ簡単にインストールできます。MongoDB ダウンロードページには、Mac OS X、Linux、Windows、Solaris用のバイナリが提供されています。また、必要であればソースコードを自分でコンパイルすることもできます。
ここでは、いくつかの OS へのインストール方法を紹介していきます。

なお、各OS共に 32bit 版と 64bit 版の2種類が用意されていますが、64bit OS であれば 64bit 版のインストールを推奨します。32bit 版の MongoDB プロセスは、約 2.5GB のデータに制限されます。

Mac OS X へのインストール

Mac OS X へのインストールにはパッケージマネージャを使うのが楽です。ここでは、Homebrew でのインストール方法をご紹介します。
Homebrew で MongoDB をインストールするには、ターミナルで下記のコマンドを実行します。


$ brew update
$ brew install mongodb

インストール時に表示されるメッセージに従って、インストールを完了させます。
初めてのインストールで、ログイン時に自動起動させる場合は、以下のような感じになります。


$ mkdir -p ~/Library/LaunchAgents
$ cp /usr/local/Cellar/mongodb/2.0.0-x86_64/org.mongodb.mongod.plist ~/Library/LaunchAgents/
$ launchctl load -w ~/Library/LaunchAgents/org.mongodb.mongod.plist

Linux へのインストール

ここでは、パッケージを使ったインストール方法をご紹介します。

CentOS / Fedora へのインストール

yum リポジトリが提供されているので、お使いのシステムに合わせて /etc/yum.repos.d/10gen.repo に下記を書いて、リポジトリを登録します。

64bit 版


[10gen]
name=10gen Repository
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64
gpgcheck=0

32bit 版


[10gen]
name=10gen Repository
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/i686
gpgcheck=0

その後、yum でインストールし MongoDB サーバーを起動しましょう。


$ sudo yum install mongo-10gen mongo-10gen-server
$ sudo /etc/init.d/mongod start

なお、システム起動時に開始するようにしたい場合は、chkconfig コマンドで登録します。


$ sudo chkconfig --add mongod

Ubuntu へのインストール

apt リポジトリが提供されています。
ここでは、最近の Ubuntu へのインストール方法を紹介しますが、 SysV 形式の init スクリプト（Debian Lenny や古い Ubuntu）の場合は、 MongoDB マニュアルの Ubuntu and Debian packagesを参照してください。

最初に、下記のコマンドで GPG キーを登録します。


$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10

その後、/etc/apt/source.list に下記を追記し、リポジトリを登録します。


deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen

下記コマンドで MongoDB をインストールします。


$ sudo apt-get update
$ sudo apt-get install mongodb-10gen

Windows へのインストール

Windows へのインストールは、インストーラなどがないため少しだけ作業が必要です。

MongoDB ダウンロードページから、Windows 用のバイナリをダウンロードします。
解凍すると「mongodb-win32-XXXX-2.0.0」のようなフォルダが出来るので、それを適当な場所に移動させます。（ここでは、mongo にフォルダ名を変え、c:\mongo に設置したものとします。）

データディレクトリの作成

エクスプローラなどで DB データが保存されるディレクトリを作成します。


c:\data\db

サービスとして登録する

Windowsキー + R で、cmd と入力してコマンドプロンプトを表示し、以下のコマンドでサービスとして登録します。


c:\> cd c:\mongo\bin
c:\mongo\bin> mongod --install --logpath c:\mongo\logs --logappend --bind_ip 127.0.0.1

サービスとして登録されたら、以下のコマンドで MongoDB をスタートさせることができます。


c:\mongo\bin > net start "MongoDB"

MongoDB シェルと戯れる

さて、詳しくは次回より紹介していきますが、ここで終わるのもなんなので、少しだけ MongoDB シェルに触れて今回は終わることにしましょう。

MongoDB シェルの起動と終了

>MongoDB シェルの起動は、mongo コマンドで行います。


$ mongo

コマンドを実行すると、下記のように表示され MongoDB シェルのバージョン 2.0.0 が起動し、test データベースに接続されたことが分かります。


MongoDB shell version: 2.0.0
connecting to: test
>

また、MongoDB シェルを終了するには exit コマンドを入力します。


exit

MongoDB シェルの特徴

MongoDB シェルは Firefox などの Javascript エンジンである SpiderMonkey を拡張した、Javascript シェルになります。今後の説明では特に明記がない限りは、このシェル上での実行例となります。
では、まずシェル上で簡単な Javascript を実行してみたいと思います。


var data = []; // 配列を初期化

for (var i = 0; i < 1000; i++) {
  // 配列に num, text 値を持ったオブジェクトを追加
  data.push({
    num: i,
    text: 'test' + i
  });
}

上記の例では、何も DB への操作をしていませんが、Javascript が実行されているため、


print(data.length);
print(data[100].text);

と実行すると、


1000
test100

とそれぞれ返って来ると思います。
この機能は、テストデータを挿入する場合などにも非常に便利に使えるでしょう。

では、少しだけ DB への操作もしてみましょう。
MongoDB のコマンドやクエリを知らなくても、その雰囲気を感じていただければと思います。
まずは、データの保存です。先ほどのデータを保存します。


use first_mongo; // DB の選択

for (var i = 0; data.length; i++) {
  db.test.save(data[i]);
}

4 行目で保存をしているのが MongoDB を知らなくても何となく分かるかと思います。
次にデータがきちんと保存されているかを確認したいと思います。まずは、データ件数を確認してみます。


db.test.count();

正常に保存されていれば、1000 と返って来るはずです。
実際に保存されたデータも確認してみましょう。下記のコマンドで保存されたデータを取得します。


db.test.find();

すると、下記のように保存されているデータが返って来るはずです。（ObjectId という部分の値は環境によって異なります。）


{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d1ff"), "num" : 0, "text" : "test0" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d200"), "num" : 1, "text" : "test1" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d201"), "num" : 2, "text" : "test2" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d202"), "num" : 3, "text" : "test3" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d203"), "num" : 4, "text" : "test4" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d204"), "num" : 5, "text" : "test5" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d205"), "num" : 6, "text" : "test6" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d206"), "num" : 7, "text" : "test7" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d207"), "num" : 8, "text" : "test8" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d208"), "num" : 9, "text" : "test9" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d209"), "num" : 10, "text" : "test10" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d20a"), "num" : 11, "text" : "test11" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d20b"), "num" : 12, "text" : "test12" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d20c"), "num" : 13, "text" : "test13" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d20d"), "num" : 14, "text" : "test14" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d20e"), "num" : 15, "text" : "test15" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d20f"), "num" : 16, "text" : "test16" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d210"), "num" : 17, "text" : "test17" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d211"), "num" : 18, "text" : "test18" }
{ "_id" : ObjectId("4e78ab3e4e6d38925bd6d212"), "num" : 19, "text" : "test19" }
has more

データ挿入時に指定していない "_id" という値が定義されている以外は、データが保存されているようです。
なお、MongoDB シェルでは 1 画面で 20 件までのデータしか表示しません。その次のデータを見るためには it （iterate の略）と入力する事で、次の 20 件のデータを表示します。

それでは、今日はここで終わりですので、遊んだデータについては削除しておくことにしましょう。


use first_mongo;
db.dropDatabase(); // first_mongo データベースを削除

まとめ

今回は MongoDB をインストールし、実際に MongoDB シェルでいくつかの処理を行ってみました。
まだ何も MongoDB について説明していないような気がしますが、その雰囲気だけでもつかんで頂ければと思います。

さて、次回からは MongoDB シェルを使って MongoDB の様々な機能に入っていきたいと思います。

関連記事もどうぞ

2.0 からはじめる MongoDB
- 第0回 MongoDB の紹介
- 第1回インストール～シェルと戯れる
【番外編】MongoDB の歴史（MongoDB 2.0 まで）

MongoDB の歴史（MongoDB 2.0 まで） #mongodbjp

2011-09-14T18:09:00+09:00

つい先日の9月12日、MongoDB 2.0 が正式にリリースされました。
「2.0 から始める MongoDB」という記事を書くにあたって、MongoDB 2.0までの遷移を調べていたのですが思いのほか濃い内容になってしまい、せっかくなのでここで皆さまに共有します。

～2008年

Githubのレポジトリを見ると、ファーストコミットは2007年10月20日のこと。"first commit" というメッセージと共に30ファイル、計約2000行のコードがコミットされています。いつから開発が始まったかは定かではありませんが、2007年後半からプロジェクトがスタートしたと推測できます。
（正確な情報をご存じの方がいましたら、教えてください。）
GitHub: mongodb/mongo - first commit

Gitリポジトリのタグから察すると、2007年10月に最初のコミットが行われた後、2008年の6～7月には ver.0.0系、2008年下半期には ver.0.1系（rcのタグしかないのですが）を開発しており、MongoDB の基本的な機能を実装していたものと思われます。

2009年

2009年に入ると、ver.0.2系が2009年2月に、ver.0.9.0が 2009年4月にリリースされており、ver.1.0 に向けての最終調整に入る事になります。
2009年の半ばくらいから、ちらほらと日本でもブログなどの記事として MongoDB が登場するようになってきます。
また、この頃になると、プロジェクト管理ツールとして JIRA が導入されたようです。
MongoDB Core Server (JIRA)

2009年下半期
7月	8月	9月	10月	11月	12月
(07: ver.0.9.6) (29: ver.0.9.7)	14: (ver.0.9.8) 18: (ver.0.9.9) 24: (ver.0.9.10) 27: ver.1.0.0	(14: ver.1.1.0)	(01: ver.1.1.1) (16: ver.1.1.2) 22: ver.1.0.1	(10: ver.1.1.3)	(04: ver.1.1.4) 10: ver.1.2.0 30: ver.1.2.1 (31: ver.1.3.0)

表では、日付（JIRA 上のリリース日なので、ずれている場合があるかも）とバージョン番号を載せています。また、安定版は太字に、開発版はカッコ付きで表記してあります。
なお、MongoDBのバージョン番号は少し特殊で、0.2 ずつ上がります。マイナーバージョンが偶数のものが安定版（1.0, 1.2, 1.4 …）、奇数のものが次のリリースへの開発版（1.1 は 1.2 の開発版, 1.3 は 1.4 の開発版…）となります。（少しでも見やすいように、バージョン0.2ずつ交互に色分けして表示してあります。）

バージョン 1.0

2009年8月27日にバージョン1.0.0として、初めての正式なGAリリースが行われます。

プロダクション環境でシングルマスター、マスター/スレーブ、レプリカ・ペアをする準備が整っています。人々が望むもっとたくさんの機能があり、動作します。1.0 は非常に安定しており、コードベースは18ヶ月以上、プロダクションで使われています。

1.0 GA Released : MongoDB blog から翻訳

バージョン1.0.0のリリース後、9月～12月にかけて、1.1系が開発されます。その後、12月10日に、バージョン1.2.0がリリースされます。

バージョン 1.2

リリースノートを要約すると次のようになります。

新機能

コレクション毎への追加のインデックス

より高速なインデックス生成

Map/Reduce

JavasScript 関数の保存

設定可能な fsync 時間

いくつかの小さな機能や fix

アップグレードの注意点
1.0からのアップグレード時には、DBの更新が必要です。
master/slave
レプリケーションにおいて、小さな変更が行われました。master/slave 設定が行われている ver.1.1.2以下からのバージョンアップの際は、slaveからアップデートする必要があります。
mongoimport
mongoimportjson が削除され、mongoimport に置き換わりました。mongoimportでは、json/csv/tsv からインポートを行えます。
フィールドフィルタ
フィールドフィルタの動作が若干変更されました。以前は、フィールドフィルタを使うと、これらのフィールドを持つオブジェクトのみが返されていましたが、フィールドフィルタは（フィールドを持つか持たないか、に関わらず）出力時にのみに用いられます。以前の動作が必要な場合は、$exists を使用できます。

1.2.x Release Notes - MongoDB から抜粋翻訳

多くの改善が行われていますが、MapReduce 機能により、サーバー側で柔軟に解析や集計させることが出来るようになった事は見逃せないでしょう。

蛇足ですが、1.2で正式に取り込まれた機能で気になったものを少しだけピックアップします。

Add --version option
実は、ver.1.1.1 まで --version オプションが無かったそうな。これまでは、起動しない限りはバージョン情報を見ることが出来ませんでした。

JSON PrettyPrinter
読みやすい形で JSON を整形してくれる機能は、ver.1.1.4 で追加されました。
mongoコンソールは javascript で何でもできるので非常に重宝しているのですが、この機能がないと、大きなドキュメントは見る気になりませんね。。。

2010年

さて、年が改まって2010年を見ていきます。NoSQLが一気に有名になりバズワード化したのもこの年だったと思いますが、MongoDBはより使いやすく進化していきます。

2010年上半期
1月	2月	3月	4月	5月	6月
(20: ver.1.3.1) 27: ver.1.2.2	23: ver.1.2.3 (11: ver.1.3.2)	01: ver.1.2.4 (02: ver.1.3.3) (17: ver.1.3.4) (22: ver.1.3.5) 25: ver.1.4.0	07: ver.1.2.5 (09: ver.1.5.0) 14: ver.1.4.1 27: ver.1.4.2	(03: ver.1.5.1) 24: ver.1.4.3 (27: ver.1.5.2)	(17: ver.1.5.3) 29: ver.1.4.4

バージョン 1.4

2010年3月には ver.1.4 がリリースされました。

1.2 から 1.4 へのアップグレードは、mongod をシャットダウンし、新しいバイナリを起動するだけです。
コアサーバーの強化

並列処理の向上

インデックス時のメモリーの改善

バックグラウンドでのインデックス生成

正規表現のより良い検出

レプリケーション & シャーディング

スレーブ再起動時のよりより処理

スナップショットからの高速な新しいスレーブ

設定可能なスレーブディレイ

マスターでのレプリケーション処理クロックの非対称化

$inc レプリケーションの fix

デプロイ & プロダクション

プロファイリングのための "slow threshold" 設定

生ファイルのバックアップのための fsync + lock

DB ごとのディレクトリ分割のオプション

http でのサーバーステータス取得

REST インターフェース

DB コマンドでのログトーテート

serverStatus コマンドの強化

新ツール mongostat

クエリ言語強化

正規表現での $all

$not

配列要素の部分マッチ $elemMatch

配列のアップデートのための$ オペレータ

$addToSet

$unset

マッチしたオブジェクトの $pull サポート

配列インデックスでの $set

Geo

2D の地理空間検索

Geo $center, $box 検索

1.4 Release Notes - MongoDB から抜粋翻訳

ver.1.4 は MongoDB 全体に渡って、様々な機能強化や改善が行われました。かゆい所に手が届かない事が以前はありましたが、このバージョンできちんと手が届くプロダクトに進化していると言えるでしょう。
GeoIndex（地理空間へのIndex）への対応も特筆に値するユニークな機能でしょう。
また、ver.1.6 で正式にリリースされるシャーディングの布石としての機能がこのバージョンで追加されているのも、見逃せません。

2010年下半期
7月	8月	9月	10月	11月	12月
(02: ver.1.5.4) (16: ver.1.5.5) (24: ver.1.5.6) (30: ver.1.5.7)	(03: ver.1.5.8) 05: ver.1.6.0 17: ver.1.6.1 31: ver.1.4.5	01: ver.1.6.2 (04: ver.1.7.0) 23: ver.1.6.3 (28: ver.1.7.1)	26: ver.1.6.4 (29: ver.1.7.2)	(16: ver.1.7.3) 20: ver.1.6.5	(21: ver.1.7.4)

2010年8月には、ver.1.6.0 がリリースされます。

新機能

シャーディング

レプリカセット

改善

$or クエリー

並列処理の向上

$slice オペレータ

コレクション毎に64個のインデックスが可能に（これまでは40個でした）

64-bit integer がシェルで NumberLog を使って表されるように

findAndModify での Upsert をサポート

ドキュメントのディスクロケーションを表示する $showDiskLoc オプション

IPv6 と UNIX ドメインソケットのサポート

Windows サービスの向上

1.6 Release Notes - MongoDB から抜粋翻訳

ver.1.6 ではシャーディングが production-ready として正式に追加されました。また、レプリケーション機能においてもレプリカセットがリリースされ、より幅広いニーズに応えられるようになりました。
この、シャーディングとレプリケーションにより、水平スケール、バックアップ、フェイルオーバーなどの巨大なデータや安定性に必要不可欠な機能が一通り出そろったといえるでしょう。

また、この頃になると、日本でも MongoDB の情報が様々なところで見られるようになってきます。MongoDB JP が立ち上がったのも11月。その翌月に「第1回 MongoDB JP & CouchDB JP 合同勉強会」が開催されるなど、ユーザー数も急激に増加していたと思います。

2011年

2011年上半期
1月	2月	3月	4月	5月	6月
(26: ver.1.7.5)	(14: ver.1.7.6) (23: ver.1.8.0-rc0)	(04: ver.1.8.0-rc1) (09: ver.1.8.0-rc2) 16: ver.1.8.0	06: ver.1.8.1	(02: ver.1.9.0)	17: ver.1.8.2

2011年3月には ver.1.8 がリリースされました。

新機能

ジャーナリング

Sparse, Cavered インデックス

インクリメンタル Map/Reduce サポート

1.8 Release Notes - MongoDB から抜粋翻訳

大きな機能としては、write-ahead（書き込み前に）ログを取ることで、素早いクラッシュリカバリと耐久性を助けるジャーナリング機能や、特定の検索を高速化する Sparse, Cavered インデックス、より柔軟な Map/Reduce をサポートするオプションの追加、などが挙げられます。
特に、ジャーナリングのサポートは、耐久性、信頼性の向上に寄与する機能で、プロダクトで使用する際には心強い機能です。
リリースノートには小さくしか記載されていないのですが、個人的には、Geoインデックスが球体対応し、ほぼ正確な地球上の距離を使用してのソートなどが可能になったことも見逃せない向上点です。

2011年下半期
7月	8月	9月	10月	11月	12月
(26: ver.1.9.1)	(15: ver.1.9.2) 22: ver.1.8.3 (25: ver.2.0.0-rc0)	(02: ver.2.0.0-rc1) (07: ver.2.0.0-rc2) 12: ver.2.0.0 *29: ver.2.0.1	04: ver.1.8.4 (04: ver.2.1.0)	(01: ver.2.1.1) (29: ver.2.1.2)

9月14日以降のリリース（*）については、目標であり正式なものではありません。

現時点での最新版である MongoDB 2.0.0 がリリースされたのは12日でした。

新機能

Compact コマンド

Concurrency の改善

デフォルトスタックサイズ

Indexの強化

セキュリティ

Sharding 認証機能

Replica Sets

Priority

Data-center awareness

w : "majority"

マイノリティの復帰の際の再設定

Primary が secondary を見つけられない場合、ステップダウン不可能に

Extended shutdown on the primary to minimize interruption

メンテナンスモード

Geospatial Features

マルチロケーションドキュメント

ポリゴンサーチャー

Journaling の強化

バルクインサートのための新しい ContinueOnError オプション

Regex オプション: s

システムスキーマの変更(field changes)

2.0 リリースノート - MongoDB から抜粋

さすが、メジャーバージョンアップだけあって、様々な機能が追加されています。
ここでは、それぞれの機能を紹介しませんが、主に、開発・運用のしやすさに対する機能（クエリやコマンド、セキュリティ機能など）追加とその改善、そして、信頼性やスケーラビリティなどのための機能追加やその改善などが特に注力されているように思います。
レプリカセットの機能として、クラウドでの利用をサポートするために、データセンターやロケーションに対しての柔軟なオプションが設定できるようになったことも大きな進化です。

最後に

こうやって一気に歴史を追ってみると、MongoDB の設計思想である柔軟性、パワー、スピード、そして簡単に使えることをきちんと追求していることが垣間見れた気がします。
（設計思想については「2.0 からはじめる MongoDB - 第0回 #mongodbjp : 今日も適当ダイアリー」で取り上げています）

きっと今後も MongoDB はより柔軟に、よりパワフルに、より高速に、より簡単になっていくでしょう。そんな MongoDB にこれからも目が離せませんよ！

関連記事もどうぞ

2.0 からはじめる MongoDB
- 第0回 MongoDB の紹介
- 第1回インストール～シェルと戯れる
【番外編】MongoDB の歴史（MongoDB 2.0 まで）

2.0 からはじめる MongoDB - 第0回 #mongodbjp

2011-09-14T00:09:00+09:00

一部の方から“SymfonyのMongoDBの人”などと呼ばれたりしますが、実はSymfonyもMongoDBも業務では使っていない、という痛い感じの @madapaja です。

大事なことは最初に言う。という事で、宣伝から始めます。
ここ1年で急伸している MongoDB。日本でもMongoDB JP（MongoDBの日本ユーザー会）が去年の11月18日に立ちあがって以来、勉強会やカンファレンス等も開かれ、盛り上がりは加速し続けています。
MongoDBをもっと知りたい、と思ったら、以下のGoogle グループや勉強会にもぜひ参加してください！みんなでMongoDBを楽しみましょう。
MongoDB JP | Google グループ
 「第6回 MongoDB 勉強会 in Tokyo」 : ATND（すでに定員オーバーしてますね。。。）

と大見得を切ったので、MongoDB について最初から優しく丁寧に解説していこうと思います。
ただ、とても一回で終わりそうにないので、これから複数回にわたって MongoDB の基本的な使い方を書いていこうと思います。

さて、今回は「0回目」として、MongoDB のメリット・デメリットやユースケース、特徴を通して“MongoDB とはなんぞや”という部分をお話します。（たぶん割と退屈な内容です。。。）

今回のアジェンダ

設計思想
デメリット
ユースケース
特徴

MongoDB がデータベースで、NoSQL の一つだって知っている人は多いと思いますが、そもそも、MongoDB ってどんなもので、どんな事が出来るのでしょうか。

MongoDB の設計思想

右図は、MongoDB が目指すものとして紹介されている図ですが、MongoDB では KVS と同等のスケーラビリティとパフォーマンス、RDBMS に近い機能性の高さを目指して作られています。

MongoDB は柔軟性、パワー、スピード、そして簡単に使えることの4つに注力し開発されており、下記のような特徴があります（そう目指して開発されています）。

JSON（正確には、BSON - Binary JSON）でデータを扱います。JSON は、プログラミング言語のネイティブな型とマップでき、スキーマレスです。柔軟性が高く、理解・管理しやすく、関連性を内部的にグループ化することで卓越したパフォーマンスを生みます。
パフォーマンスと共に、純粋な KVS とは一線を画した機能性の高さのニーズに応えます。MongoDB では、セカンダリインデックスや動的なクエリやソート、リッチなアップデートや集計など、これまでのRDBMSのような多くの機能を提供します。
水平スケーリングが容易で、オート・シャーディングにより、ダウンタイムなく容量の増加に対応することも可能です。
多くの環境で（どこでも）動作し、インストール・設定・メンテナンスそして、使用が容易で、開発に専念できます。

MongoDB のデメリット

また、MongoDB のデメリットには下記のようなものが挙げられるでしょう。

トランザクション、JOIN が無い
メモリを食う（インデックスがメモリに乗らなくなると性能劣化が激しい）
歴史が浅い（MySQLやPostgreSQLなどのRDBMSと比べて）

ユースケース

メリットとデメリットから、以下の条件に当てはまる場合、MongoDB に向いています。

高速なデータのインサート・アップデートが必要
豊富で柔軟なクエリが必要
スキーマレスなデータの保存
一貫性（トランザクション）を保てない場合があるのが許容できる

具体的に上げると、次のようなシステムに向いています。

CMS
リアルタイム統計
アーカイブやイベントログ
コメントや投票データ
セッションデータ
Eコマース（RDBMSとの組み合わせで。最終的な注文・会計処理ではトランザクションのあるRDBMSを使うべきでしょう）
ゲーム/モバイル（MongoDBには地理情報インデックスもあります！）
イテレーティブ/アジャイル開発での利用

参考：ユースケース MongoDB マニュアル

MongoDB の特徴

さて、MongoDBの主な機能を俯瞰することで、MongoDB で何が出来るのかを見ていきましょう。

MongoDB の公式ホームページにはこう書かれています。

素早くて、スケーラブル
MongoDB （"humongous" = どでかい）は、スケーラブル、ハイパフォーマンス、オープンソースなドキュメント指向データベースです。C++で書かれ、以下のような特徴があります。

ドキュメント指向ストレージ

完全なインデックスのサポート

レプリケーション & 高可用性

オート・シャーディング

クエリ

高速な in-place（その場での）アップデート

Map/Reduce

GridFS

コマーシャルサポート

各々の特徴について簡単に見ていきましょう。

ドキュメント指向データベース

RDB（リレーショナルデータベース）では、テーブル（表）を定義した上で、データをレコードとして保存し、複数のテーブルを連結（join）することで、様々なデータを保存します。
対して、ドキュメント指向データベースでは、それぞれのデータをドキュメントとして保存し、それぞれのドキュメントはスキーマレス（RDBでいうテーブル定義が必要ない）なので、柔軟なデータを入れることが出来ます。

MongoDBではドキュメントを保存するために、JSON（正確には、BSON - Binary JSON）を用いています。

MongoDBから、2つのドキュメントを取得した例（コメントは私が追記）：


// 1つ目のドキュメント
{
  "_id" : ObjectId("4e6efb28dbfb278da997d208"),
  "title" : "はじめてのMongoDB",
  "tags" : [ "mongo", "db" ], // もちろん配列もOK
  "created" : ISODate("2011-09-01T12:00:00Z")
}
// 2つ目のドキュメント
{
  "_id" : ObjectId("4e6efb7edbfb278da997d209"),
  "title" : "PHPでハマった",
  "tags" : [ "php" ],
  "created" : ISODate("2011-09-05T13:00:00Z"),
  "modified" : ISODate("2011-09-06T02:00:00Z")
}

フル・インデックスのサポート

必要な時に、どの属性にもインデックスを作れます。
インデックスはクエリーのパフォーマンスをとても向上させます。MongoDB では RDBMS のようなインデックスを、簡単に作る事ができます。

レプリケーション & 高可用性

スケールと心の平和のために、LAN、WANにまたがったミラーリングを提供します。
MongoDB では、バックアップやフェールオーバーに備えて、マスター-スレーブやレプリカセットといった、柔軟なレプリケーションオプションがあります。

オート・シャーディング

機能性を損なわない水平スケーラビリティを提供します。
MongoDB には、負荷やデータ分布、マシンの追加などの変化に伴って自動的にスケールアウトできる、シャーディング機能があります。また、1000ノード以上でのスケールアウトでき、自動フェイルオーバー機能も備えています。

クエリ

リッチなドキュメントベースのクエリを提供します。
好きな条件で柔軟に検索できるクエリが使えるため、RDMBS からの移行でもクエリが物足りなく感じることはないでしょう。

高速な in-place（その場での）アップデート

MongoDB は、ドキュメント全体を入れ替えるための通常のアップデートだけでなく、アトミック、インプレース（その場での）アップデートをサポートしています。

Map/Reduce

柔軟な集約やデータ処理を提供します。
バッチでのデータ処理や集計の際に便利な MapReduce を MongoDB では備えています。

GridFS

MongoDB の GridFS を使うことで簡単に巨大なサイズのファイルを保存できます。

コマーシャルサポート

エンタープライズ向けのサポート、トレーニング、コンサルティングを MongoDB の開発元である 10gen が提供しています。

最後に

今回は MongoDB の軸となる部分をまとめましたが、本当に「はじめて」の方にはちんぷんかんぷんな内容も多かったと思います。
ただ、MongoDB の目指しているものと、特徴的な機能をまとめたものですので、頭の片隅に置いておくと、今後、理解しやすいかもしれません。

さあ、次回の第1回からは実際に MongoDB をインストールし、動かしながら話を進めていきましょう。

関連記事もどうぞ

2.0 からはじめる MongoDB
- 第0回 MongoDB の紹介
- 第1回インストール～シェルと戯れる
【番外編】MongoDB の歴史（MongoDB 2.0 まで）

TDDBC Tokyo 1.7 for PHP に参加して #tddbc

2011-09-09T12:09:00+09:00

8/21（日）にタイレルシステムズさんの TDDBC Tokyo 1.7 for PHP に参加してきました。
すでに3週間が経とうとしてますが、あの時感じた事や、今想う事をここに書いておきます。（なので、TDDのやり方やブートキャンプ部分については、今回は触れていません。。。）

なお、TDDBCについてのまとめ記事は主催者である @shishi4tw さんが書かれた記事が詳しいので、そちらをどうぞ。
It's just same as dust ahead of a wind: TDDBC Tokyo 1.7 for PHP を開催しました
http://shishithefool.blogspot.com/2011/08/tddbc-tokyo-17-for-php.html

今回のTDDBCの内容は大きく2つにわかれ、1つめは日本のTDD先駆者である @t_wada 氏によるTDD（BC）についての基調講演を中心とした（いわゆる普通の）勉強会の部分、2つめはTDDをペアプログラミングで実践してみるTDDBCのBCの部分です。

@t_wada 氏による基調講演では、TDDの前提から、基本的な事を丁寧に説明がありました。その中でも、TDDに限った話ではないのですが、そもそもエンジニアとしてどうあるべきか、という部分が心に刺さりました。
それは、エンジニアとしての自分にやましい部分を感じていたからだと思います。

良心のある開発者でいたい。
動く綺麗なコードを作りたい。

そう思いながら、そう出来ていない自分がいます。悩み、改善しなければ、と思いつつも、「スケジュールが…」とか、「うちの会社じゃ…」とか言って、先延ばしにする。見えないフリをしている。
そんなやましい自分に正面から向き合うように言われた気がしたのです。

完璧主義の呪い

「きれいなコード」、「動くコード」を書こうとした場合について、和田さんは以下のように説明されました。

良い設計を行おうとすると、設計から逃れることができない。
きれいな設計には終わりがない。
→いつまで経ってもコードが書き始められない
→でも、コードを書き始めて気付く事は非常に多い
→完璧な設計だと思って始めたら、全然完璧じゃない

また、「動かして学ぶことで学ぶ点が多い」ことも挙げて、「動くコード」を書くことを最初にやると「動くけど汚い」コードで止まってしまう。

そして、動くコードをきれいなコードにしていくことで、これらの問題を解決しよう、という実践的な試みが「TDD」である、と。
「きれいなコードにする事をあきらめない」ために、TDDの心として挙げれていたものが重要だと思ったので、以下に簡単にまとめます。（メモ書きですが）

一つずつ、少しずつ

大きな問題を、小さくすぐに達成可能な分解された問題の連続にする
大きな問題を制御可能に

一人ずつ仕留める

一対多を一対一の連続にすれば、負けることはない！

すばやくまわす

サイクルが速ければ速いほど開発が加速化される
1〜2分でテストコード、1分でコードを書いて、3分でリファクタリング、を目標にしてみたら？

サイクルのスピードを保ち続ける
開発が進んでくるとスピードが落ちがち。でも、様々なテクニックを駆使してそのスピードを維持！

自分が最初のユーザー

自分がテストコードを書く→自分の書くコードの最初のコードが自分自身になる
テストコードを書く＝利用者視点に立てる

道具にこだわる

プロフェッショナルとして道具にこだわる
どれが一番効率的か
エディタ、IDE、そのほかのツール…

不安をテストに

不安に対してテストコードを書く
何を自分の手を止めるか→不安によるもの
テストの粒度はものによって異なる
getter/setterにテストコードは必要？→基本的には不要では？
不安なものは、不安を解消できるテストを書く

祈るのではダメ

機能追加・修正でバグは生まれないか？
→祈るのではダメ！
→日々のコーディングの中でテストコードを書く・整備すること

テストが命綱

必要な時にテストを書くでは遅い
→テストコードを書くモチベーションを保ち、日々書いていこう

TDDの真の目的は「健康」

健康体のコード（無駄のない、引き締まった体を持ったコード）
健康体のチーム
健康体の自分

これらがあって、変化に柔軟に対応できるコード（プロジェクト）になる。
そして、テストを書くことで、不安を克服できる。

テストは目的ではなく手段、である。

即座にフィードバックを得る
書いたコードに自身を持つ
これから書くコードに自信を持つ

ためにテストを書き、リファクタリングできれいにすることで、「健康を維持」しよう。

私たちは完璧なプログラマーではない事を自覚し、その上で、プロフェッショナルであり続けるために、いろいろな事を学び、改善し続けなければならない、と深く感じた一日でした。

最後になりましたが、主催された @shishi4tw さん、講演された @t_wada さんを始めスタッフ・参加者の皆さん、本当にありがとうございました！

acts_as_professional !

Git のおさらい

2011-08-22T13:13:15+09:00

8/21（日）にタイレルシステムズさんに会場提供いただいて行われた TDDBC Tokyo 1.7 for PHP に参加してきました。
参加登録に出遅れ補欠だったのですが、@shishi4tw さんから、

LT してくださる方を 1 名補欠の方の中から募集します。LT してくださる方は LT 枠として、本編にも参加していただけるようにします。題材は広く PHP や TDD に関することなら何でも良い、つまり、開発に関することなら何でも良い、とします。

との言葉をいただき、参加したかったので、LT表明をして参加させていただけることになりました。

そこで、「Gitのおさらい」というLTをしてきましたので、その内容をまとめておきます。
なお、勉強会本編の感想は別記事でアップする予定です。
下にあるスライドと併せてお読みください

Git

「ぎっと」と読みます
バージョン管理システムの一つ
- CVS, Subversion, Git, Mercurial ...
その中でも、分散バージョン管理システムの一つ
- Git, Mercurial, Bazaar ...
みんな使ってる！
使いこなせたらかっちょいい

分散バージョン管理システム

リポジトリが複数ある

集中型バージョン管理システム（CVS、Subversionなど）では、開発者は、サーバー上などにある唯一のリポジトリに対してチェックアウトやコミットを行います。

それに対して、分散バージョン管理システムでは、開発者は、サーバー上などにあるリポジトリから、リポジトリをコピー（clone）し、そのコピー（ローカルリポジトリ）に対してコミットやブランチなどの作業を行います。

つまり、マスターリポジトリの他に、Aさんのローカルリポジトリ、Bさんのローカルリポジトリ……のように、複数のリポジトリが存在します。（システム的にはそれぞれのリポジトリは優劣はなく、マスターリポジトリが無くても構わない。）

気軽にコミットできる

ローカルリポジトリへのコミットは他人に影響しないため、気軽にコミットしたり、ブランチを切って実験的な試みをすることができます。（心理的な障壁がとても少ない）

集中型バージョン管理ではコミットすると、プロジェクトメンバーの全員にその変更が伝わるので、ちょっとした作業とか、汚い状態ではなかなかコミットし辛かったですよね。（それに無駄にリビジョン番号が上がってくのも。。。）

速い

コミットやブランチなどの日常的に行う操作がローカル内で完結し、いちいちリモートのリポジトリに問い合わせる必要がないので、集中型-よりも速いです。

マスターリポジトリへの同期や変更の反映はコミットとは別の任意のタイミングで行える

マスターリポジトリとの同期（fetchやpull）や変更の反映（push）などは、任意のタイミングで行えます。

なので、実験的な試みをローカルリポジトリ内で育てていって、ある程度固まったタイミングでマスターリポジトリに反映させたりできますし、もちろん、ネットワークの環境がない場合でも、ローカルリポジトリへのコミットなどの作業を行えます。

オブジェクトについて

Gitではプロジェクトの状態などを記録するために、データをオブジェクトという単位が使われています。また、そのオブジェクトにはいくつかの種類がありますが、すべて下記の形式で保存されています。

オブジェクトのヘッダーとデータを結合し、その「SHA-1ハッシュ」を取った値（16進数40文字）がオブジェクト名（オブジェクトIDと呼ばれることも）となり、このオブジェクト名をキーとして、オブジェクトDBにデータが（実際には圧縮されて）保存されます。

Gitでは、このオブジェクト名がコミットやファイルなどを一意に特定する際に用いられます。

オブジェクトの型は下記の4つのようです。

blob オブジェクト

ファイルデータを格納します。ファイル名や権限情報などは保持せずに、データ部にファイルの内容がそのまま入ります。

例：

tree オブジェクト

1つ以上のblobオブジェクトやtreeオブジェクト（サブディレクトリ）を参照することで、ディレクトリ/ファイル構成を格納します。
ファイル/ディレクトリ名やファイル権限なども保持します。

例：

commit オブジェクト

コミット情報を格納します。下記のようなデータが保持されます。

tree	ルートディレクトリのtreeオブジェクト名
parent	（この）コミットが作られる元となったコミット（ひとつ前のコミット）。マージの際などのように、元となるコミットが複数ある場合は、parentも複数ある。下記の例のようにparent項目が無い場合は、前のコミットが無いルートコミット（最初のコミット）
author	Author情報
comitter	Comitter情報
-	コミットコメント

例：

tagオブジェクト

コメント付き、署名付きタブを格納します。
（$ git tag stable-1 などとして作られる軽量タグの場合は、オブジェクトは作られません。）

インデックスについて

Gitではリポジトリとワークツリー（作業ディレクトリ）の間に、インデックスという領域があります。

インデックスは、ステージングエリアと呼ばれることもあり、プロジェクト全体のスナップショット（treeオブジェクトを生成するための情報）、ツリー間のコンフリクト情報や3-wayマージのためのツリー情報などを保持しています。

コミットやチェックアウトなど、リポジトリとワークツリー間のやりとりにはインデックスが経由されます。

2.チェックアウト（checkout）を行うと、リポジトリの内容がインデックスとワークツリーに展開されます。
4.編集後、インデックスへの反映（add）を行うことで、ワークツリーのスナップショットがインデックスに記録されます。
5.コミット（commit）を行うと、インデックスの内容がリポジトリにコミットされます。（ワークツリーの状態がコミットされるのではない）

下記の図のように、インデックスへの反映（add）後にワークツリーを再編集して、コミット（commit）した場合、再編集した内容ではなく、インデックスへの反映（add）時の状態がコミットされます。

再編集した内容をコミットしたい場合は、下記の図のように、再度インデックスへの反映（add）を行う必要があります。

プロジェクトの開始

新しいプロジェクトを作る

$ cd path/to/project
$ git init

既存のプロジェクトを取得

$ git clone git://path/to/project
$ cd project

インデックス-ワークツリー間に対する操作

indexにファイルのスナップショットを追加

$ git add target.php  # 対象ファイルを指定

$ git add -u          # 変更されたファイルの追加

indexからの削除

$ git rm --cached target.php # ワークツリーのファイルは残す

$ git rm target.php          # ワークツリーのファイルも削除

ステータスの確認

$ git status

index-ワークツリーのdiff

$ git diff

indexからチェックアウト

$ git checkout target.php

indexへの変更を無かったことに

$ git reset HEAD target.php

リポジトリ-インデックス間に対する操作

リポジトリ-インデックスのdiff

$ git diff --cached

インデックスの内容をコミットする

$ git commit

コミットをやり直す

直前のコミットを無効にして、新しいcommitオブジェクトを生成する。

$ git commit --amend

コミットを取り消し、その内容をindexに戻す

$ git reset --soft HEAD^

リポジトリ-ワークツリー間に対する操作

リポジトリ-ワークツリーのdiff

$ git diff HEAD

変更されたファイルをコミットする

git add -u && git commit と同じ

$ git commit -a

ワークツリーを指定したコミット時点の状態に戻し、コミットする

$ git revert a5102ef4

コミットを取り消し、ワークツリーの内容も書き換える

$ git reset --hard HEAD^

ブランチの内容をチェックアウト

$ git checkout master

ブランチを作り、その内容をチェックアウト

git branch branch1 && git checkout branch1 と同じ

$ git checkout -b branch1

コミット間をマージし、結果をワークツリーに反映

マージ結果を自動でコミット

$ git merge new_function

マージ結果をコミットしない
$ git merge --no-commit new_function

リポジトリ内での操作

ログを見る

$ git log

コミット間のdiff

$ git diff HEAD^..HEAD

ブランチの確認

$ git branch

ブランチの作成

$ git branch experimental

ブランチの削除

$ git branch -d experimental
$ git branch -D experimental  # 強制削除

リモートリポジトリへの操作

リモートブランチの確認

$ git branch -r

リモートブランチを複製元リポジトリの最新バージョンの状態に更新

$ git fetch origin

リモートブランチの内容をローカルブランチにマージ

$ git merge origin/master

リモートリポジトリから変更をプル

git fetch origin && git merge origin/master と同じ

$ git pull origin master

リモートブランチの削除

$ git push origin :experimental

リモートリポジトリに変更をプッシュ

$ git push origin master

まとめ

オブジェクトとインデックスを理解して、よりgitを直感的に使いこなしましょう！

スライド

Gitのおさらい

View more presentations from madapaja

参考

入門Git

作者: 濱野純(Junio C Hamano)
出版社/メーカー: 秀和システム
発売日: 2009/09/19
メディア: 単行本
購入: 31人クリック: 736回
この商品を含むブログ (158件) を見る

http://progit.org/book/ja/

反省

Gitは「ぎっと」と呼びます。どうしても「じっと」と読んでしまう自分に反省。
10分で収まる内容じゃなかった。。。

Symfony温泉に参加してきました！ #trspa

2011-07-27T22:01:38+09:00

[テトラポッドで作業をする人々]

Symfonyユーザー会で企画された温泉ツアーに参加しました。
今回は、主にリリースが迫った Symfony2 のドキュメントの翻訳を一気に進めよう、ということで、7月23日（土）〜24日（日）の一泊二日で静岡県伊東の旅館に行ってきました。

旅館に着いて一発目、靴箱に書かれた「シンポニーユーザー会」の文字で吹き出してしまいました。
旅館の粋な計らい。侮れませぬ。

私は、短めのドキュメントを2つ翻訳したのですが、久しぶりに翻訳をして日本語がやっぱり難しいな、と改めて感じました。
結局の所、自然な日本語を作るのが難しい。
ですが、これをきっかけに、SymfonやMongoDBのドキュメント翻訳に出来る範囲で貢献していけたらいいな、と思っています。

それにしても今回のツアーでは翻訳をしていたのに、いつの間にかMacやGitの勉強会になったり、大喜利大会になったりして、なかなかユニークで面白くて有意義な2日間でした。

まとめ：Symfonyユーザー会にはツッコミが多い

他の参加者の日記：
http://yanchi52.blog21.fc2.com/blog-entry-40.html
http://d.hatena.ne.jp/n416/20110726/1311645557
http://shishithefool.blogspot.com/2011/07/2-symfony.html

[symfony2][mongo]「第4回 Symfony2 勉強会」でも、Symfony2でMongoDBと仲良くする方法についてLTしてきました

2011-06-06T20:59:13+09:00

2011-06-06 に ZyngaJapan さんで開催された Symfony2 勉強会でLTをしてきました。

今回の勉強会では MongoDB 周り以外にもちょっと応用的な内容（動的なフォーム、バリデーションなど）を含むことをやろうと思っていたのですが、あえなく挫折。
そして、時間的に押し押しになっていたことと、LTにしては欲張り過ぎたのか、全然説明できずにLTは終わってしまった感があります。。。
が、スライドは丁寧に書いたので、そちらを見ていただけると嬉しいかな、と思います。
また、これを機に、Symfony2やMongoDBを触り始めていただければ、なお嬉しいかな、と思います。

なお、下記のスライドやサンプルコードは、Symfony2 Beta1 での動作を確認しています。
将来のバージョンでは動かなくなってしまうかも知れませんが、また改めて、このブログでも取り上げようと思いますので、一緒にSymfony2 + Mongoしましょう！

スライド：

Symfony2でMongoDBと仲良くする方法

View more presentations from madapaja

http://www.slideshare.net/madapaja/symfony2mongodb

サンプルコード：
https://github.com/madapaja/MadapajaMongoWikiBundle

ツッコミお待ちしてます！

「第2回 Symfony2 勉強会」でSymfony2からDoctrine MongoDB ODMを使ってみる、というLTをしてきました！

2011-01-17T11:07:35+09:00

2011-01-15にZynga Japanさんにて開催された、Symfony2 勉強会でLTをしてきました。
内容は、Symfony Adventで書いた記事をざっくりまとめ、現時点での最新情報に更新しただけなのですが、Symfony2+MongoDB ODMの基本的な使い方をご紹介しました。

Symfony2からdoctrine mongo db odmを使ってみる from madapaja

この勉強会は、なかなかスパルタ、というか、あまり説明をしないで、とりあえず作ってみやがれ！的なノリで進行していくので、事前情報なしだと結構ひぃひぃですｗ
でも、やはり、習うより慣れろじゃないですけど、やっぱり最初はトライ＆エラーを重ねていくしかないわけで。
それこそ、フレームワーク始めて！っていう方から、Symfonyのスペシャリストまで、いろいろな方がいる中で、こーすればいいよ！だったり、あーでもない、こーでもないというやり取りをしていくのは、適度な緊張感があって面白いです！

勉強会全体については、日本ユーザー会の下記ページをご覧ください。
http://symfony.gr.jp/blog/20110116-symfony2-workshop2-report

@hidenorigoto さん、Zynga Japanの皆様を始め、運営の皆様、参加者の皆様、本当にありがとうございました！
私も十分に楽しみましたよ！

Symfony2 + MongoDB ODM を使ってみる

2010-12-14T02:47:19+09:00

この記事は、Symfony アドベントカレンダー2010 に参加しています。

投稿時の設定を間違え、12/14付けになっちゃってますが、Adventカレンダー15日目の記事です！（投稿も15日早朝です）
日付変えちゃうとURL変っちゃうのでそのままにしてありますが、ご容赦くださいませ〜

と発言したので、今回は Doctrine MongoDB ODM を Symfony2 から使ってみる。という、割と初心者向けチュートリアル的な記事です。

今回使用した環境は下記の通り。

PHP 5.3.3
MongoDB 1.7.3
Symfony2 PR4
Doctrine MongoDB ODM 1.0.0 beta1
PHP Mongo Extension 1.1.0 (pecl)

MongoDB ODM ってなに？

ODM は Object Document Mapper の事で、Doctrine2 のORM（Object Relational Mapper）によく似ていて、PHP 5.3.0+ のオブジェクトをMongoDBのドキュメント（RDBのレコードに相当）として簡単に扱えるようになります。

Symfony2 から MongoDB ODM は標準でサポートされているので、早速ためしてみたいと思います。

作るもの

解説のみだとドキュメント見たほうが豊富だし、そもそも1回の記事では解説しきれないので、今回はサンプルプログラムとして“ささやきアプリケーション”を作る事にします。
まぁ、twitter的な一言掲示板アプリですね。

要件は下記の通りです。

ささやきアプリケーションの機能
- ささやき投稿
- ささやきリスト表示（ささやきを時間順（降順）で表示）
- 特定の人のささやき表示（指定した人が発言したささやきを時間順（降順）で表示）
ささやきは以下の項目で構成されます
- ID (今回は MongoDB で自動生成される MongoId を利用します)
- 名前（String）《入力項目》
- 本文（String）《入力項目》
- ささやいた時間（DateTime）

下記のような感じになる予定です。

サンドボックスを用意

今回は、サンドボックスをベースに作りますので、サンドボックスを用意します。
GitがインストールされたLinux系OSであれば、下記のような感じでしょうか。

$ git clone git://github.com/symfony/symfony-sandbox.git
$ cd symfony-sandbox/src
$ ../bin/install_vendors.sh
$ chmod 777 ../app/cache ../app/logs

アプリケーション設定の変更

では、さっそく、アプリケーションの設定を変えていきます。

app/AppKernel.php

まずは、MongoDB ODM を使うためのバンドルと、ささやきアプリケーション用のバンドルをアプリケーションに登録するために、AppKernel.phpファイルを編集します。

<?php

/* 8< 8< 8< 8< 略 8< 8< 8< 8< */

class AppKernel extends Kernel
{

    /* 8< 8< 8< 8< 略 8< 8< 8< 8< */

    public function registerBundles()
    {
        $bundles = array(
            new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
            new Symfony\Bundle\TwigBundle\TwigBundle(),

            // enable third-party bundles
            new Symfony\Bundle\ZendBundle\ZendBundle(),
            new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
            new Symfony\Bundle\DoctrineBundle\DoctrineBundle(),
            //new Symfony\Bundle\DoctrineMigrationsBundle\DoctrineMigrationsBundle(),
            new Symfony\Bundle\DoctrineMongoDBBundle\DoctrineMongoDBBundle(),
            // ↑コメントアウトを解除し、DoctrineMongoDBBundleを有効にします。

            // register your bundles
            new Application\SasayakiBundle\SasayakiBundle(),
            // ↑HelloBundleは使わないので、HelloBundleを削除し、
            // かわりにSasayakiBundleを登録します。
        );

        if ($this->isDebug()) {
            $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
        }

        return $bundles;
    }

    /* 8< 8< 8< 8< 略 8< 8< 8< 8< */

app/config/config.yml

次に、設定ファイルにMongoDB ODM の設定を追記します。

## doctrine_odm.mongodbが有効になるように追記。
doctrine_odm.mongodb: ~

ちなみに、上記設定の場合、接続などにデフォルト値が使われますので、変更したい場合はパラメータを指定する必要があります。
今回は、下記のように設定しましたが、環境に合わせて変更してください。

## doctrine_odm.mongodbが有効になるように追記。
doctrine_odm.mongodb:
    mappings:
        SasayakiBundle: ~
    server: mongodb://localhost:27077
    default_database: sasayakiapp
    options:
        connect: true
        persist: foobar

app/config/routing.yml

ルーティングルールも変更します。
今回は、Sasayakiバンドルのルーティングルールに従うように、下記のように変更しました。

homepage:
    resource: SasayakiBundle/Resources/config/routing.yml

その他の設定

もし、デフォルトのHTMLを変えたければ、お好みで app/views/layout.twig も編集しましょう。

Sasayakiバンドルの作成

下準備が整ったら、Sasayakiバンドルを作るためにディレクトリを作ります。
ディレクトリの構成は下記の通りです。

src/Application/SasayakiBundle : Sasayakiバンドルのルート
- /Controller : コントローラファイル
- /Document : ODM用のクラス（ドキュメント）ファイル
- /Resources
  - /config : 設定ファイル
  - /views : ビューファイル

src/Application/SasayakiBundle/SasayakiBundle.php

Sasayakiバンドルを有効にするために、Bundleファイルを書きます。

<?php

namespace Application\SasayakiBundle;

use Symfony\Component\HttpKernel\Bundle\Bundle;

class SasayakiBundle extends Bundle
{
}

Sasayakiドキュメントの作成

まずは、MongoDBに保存される「Sasayakiドキュメント」を作ります。

基本的には、上に書いたささやきの情報をそのままクラス化すればOKですが、MongoDB ODM を使うために「@mongodb:」から始まるコメントを記述する必要があります。

src/Application/SasayakiBundle/Document/Sasayaki.php

2010/12/15追記:
下記のサンプルでは要素をpublicプロパティで宣言していますが、Doctrine2では、private/protectedプロパティとして宣言した上で、getter/setterメソッドでアクセスする事が推奨されています。
Doctrine2マニュアル：27. Best Practices — Doctrine 2 ORM 2 documentation

<?php
namespace Application\SasayakiBundle\Document;

/**
 * -- 接続するコレクション名を指定
 * @mongodb:Document(collection="sasayaki")
 *
 * -- nameとsasayaki_atをインデックスとして登録
 * @mongodb:Indexes({
 *   @mongodb:Index(keys={"name"="asc"}),
 *   @mongodb:Index(keys={"sasayaki_at"="desc"})
 * })
 */
class Sasayaki
{
    /**
     * -- MongoID型
     * （MongoDB上では規定のプライマリキーである
     *   "_id" フィールドとして保存されます）
     * @mongodb:Id
     */
    protected $id;

    /**
     * @mongodb:String
     */
    public $name;

    /**
     * @mongodb:String
     */
    public $body;

    /**
     * -- MongoDate型 (Timestamp)
     * @mongodb:Date
     */
    protected $sasayaki_at;

    public function __construct()
    {
        // 生成時に時間が自動で設定されるようにします。
        // \DateTime を使うのがオススメ。
        $this->sasayaki_at = new \DateTime();
    }

    /**
     * return integer $id
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * return DateTime $sasayaki_at
     */
    public function getSasayakiAt()
    {
        return $this->sasayaki_at;
    }
}

id と sasayaki_at については、自動的に生成され、変更不可なので protected メンバ変数として定義し、getXXXというメソッドを使用してアクセスする事とします。

なお、通常のタイムスタンプの保存には「@mongodb:Date」を指定します。
「@mongodb:Timestamp」ではありませんので、注意してください。「@mongodb:Timestamp」で定義した場合、MongoTimestampクラスが利用され、このクラスはシャーディングで使用される特別な型となります。
MongoTimestampクラスについては、PHP: MongoTimestamp - Manualを参照してください。

注意：
ODMへのIndex関連の設定は、上記設定で通っているようなのですが、MongoDB側にちゃんと伝わっていない模様です。
なぜかは良く分かっていない（きちんと調べていない）のですが、情報をお持ちの方がいれば教えてください。。。
ODM側でのインデックス情報のチェック
<?php
    // MongoDB ODM DocumentManager を取得</span>
    $dm = $this->get('doctrine.odm.mongodb.document_manager');

    // インデックス情報を取得
    var_export($dm->getClassMetadata('Application\SasayakiBundle\Document\Sasayaki')->getIndexes());
返ってきた値（nameとsasayaki_atがそれぞれキー指定されている）
<?php
    array(
        array(
            'keys' => array('name' => 1),
            'options' => array('unique' => false),
        ),
        array(
            'keys' => array('sasayaki_at' => -1),
            'options' => array('unique' => false),
        ),
    )
MongoDB側でのインデックス情報のチェック（Mongoシェル）
> db.sasayaki.getIndexes();
返ってきた値（_idしかキーになっていない）
[{
    "name" : "_id_",
    "ns" : "sasayakiapp.sasayaki",
    "key" : { "_id" : 1 },
    "v" : 0
}]
なぜゆえ！？
2011-01-04追記
自動的にやってくれるものと勘違いしていたのですが、
下記のように明示的にインデックスを作らないといけないようです。
<?php
   $dm->getSchemaManager()->ensureIndexes();
タイミング的には、データ投入時のflush()の前あたりかと思われます。

コントローラの作成

MongoDB ODMの利用方法

さっき作ったドキュメントを使うのであらかじめ、

<?php
use Application\SasayakiBundle\Document\Sasayaki;

などとしておきます。

まず、コントローラ内で下記のようにMongoDB ODM の DocumentManager を取得しておきます。

<?php
    // MongoDB ODM DocumentManager を取得
    $dm = $this->get('doctrine.odm.mongodb.document_manager');

MongoDB へデータを保存するには、DocumentManager を取得した後に下記のようにします。

<?php
    // Sasayakiドキュメントを生成し、データを入れる
    $sasayaki = new Sasayaki();
    $sasayaki->name = '名前です';
    $sasayaki->body = 'ここにボディテキストを指定します！';

    $dm->persist($sasayaki); // データを入れて
    $dm->flush(); // 保存

データの取得は方法が何通りもありますが

<?php
    // 1. 全件取得
    $sasayaki = $dm->find('Application\SasayakiBundle\Document\Sasayaki')
        ->getResults();

    // 2. _idを指定し、1件だけ取得
    $sasayaki = $dm->findOne('Application\SasayakiBundle\Document\Sasayaki',
        array("_id" => new \MongoId("XXXXXXXXXXXXXXXXXXXXXXXX"))
    );

    // 3. リポジトリを取得し、nameがJhonのものを取得
    $sasayaki = $dm->getRepository('Application\SasayakiBundle\Document\Sasayaki')
        ->findByName("Jhon")
        ->getResults();

    // 4. createQuery でクエリを生成し、sasayaki_atを降順で取得
    $sasayaki = $dm->createQuery('Application\SasayakiBundle\Document\Sasayaki')
        ->sort('sasayaki_at', 'desc')
        ->getResult();

などの方法で取得出来ます。

ちなみに、今回は使いませんが、findAndModify を使用する事で効率的に編集・削除を行うことも可能です。

<?php
    $sasayaki = $dm->createQuery('Application\SasayakiBundle\Document\Sasayaki')
        // ささやきを探す
        ->findAndModify()
        ->field('name')->equals('Jhon')

        // アップデートします
        ->update()
        ->field('name')->set('ジョン')
        ->execute();

    $sasayaki = $dm->createQuery('Application\SasayakiBundle\Document\Sasayaki')
        // ささやきを探す
        ->findAndModify()
        ->field('name')->equals('Jhon')

        // 削除する
        ->remove()
        ->execute();

src/Application/SasayakiBundle/Controller/SasayakiController.php

では、結果として出来たコントローラは下記の通りです。

<?php

namespace Application\SasayakiBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;

use Symfony\Component\Form\Form;
use Symfony\Component\Form\TextField;
use Symfony\Component\Form\TextareaField;

// さっき作ったSasayakiドキュメントを使う
use Application\SasayakiBundle\Document\Sasayaki;

class SasayakiController extends Controller
{
    /**
     * ささやきの取得
     */
    public function listAction()
    {
        // MongoDB ODM DocumentManager を取得
        $dm = $this->get('doctrine.odm.mongodb.document_manager');

        // Sasayakiドキュメントのクエリを作成
        $sasayaki = $dm->createQuery('Application\SasayakiBundle\Document\Sasayaki')
            // 発言順（降順）にソート
            ->sort('sasayaki_at', 'desc')
            // 最初の10件だけ
            ->limit(10)
            // 取得
            ->getResult();

        return $this->render('SasayakiBundle:Sasayaki:index.twig', array(
            'sasayaki' => $sasayaki,
            'sasayakiname' => 'みんな',
        ));
    }

    /**
     * $nameのささやきを取得
     */
    public function findByNameAction($name)
    {
        // MongoDB ODM DocumentManager を取得
        $dm = $this->get('doctrine.odm.mongodb.document_manager');

        // Sasayakiドキュメントのクエリを作成
        $sasayaki = $dm->createQuery('Application\SasayakiBundle\Document\Sasayaki')
            // フィールド name が $name のドキュメントを
            ->field('name')->equals($name)
            // 発言順（降順）にソート
            ->sort('sasayaki_at', 'desc')
            // 最初の10件だけ
            ->limit(10)
            // 取得
            ->getResult();

        return $this->render('SasayakiBundle:Sasayaki:index.twig', array(
            'sasayaki' => $sasayaki,
            'sasayakiname' => $name,
        ));
    }

    /**
     * ささやきの投稿
     * モード切替のために $standalone を定義しておく（viewで使用）
     */
    public function createAction($standalone = true)
    {
        // Sasayakiドキュメントを生成
        $sasayaki = new Sasayaki();

        // フォームと結びつけて
        $form = new Form('sasayaki', $sasayaki, $this->get('validator'));

        // 入力項目を追加
        $form->add(new TextField('name'));
        $form->add(new TextareaField('body'));

        // メソッドが POST の場合
        if ('POST' === $this->get('request')->getMethod()) {
            // 送信された sasayaki を取得して
            $form->bind($this->get('request')->request->get('sasayaki'));

            // バリデーションOKなら
            if ($form->isValid()) {
                // MongoDB ODM DocumentManager を取得
                $dm = $this->get('doctrine.odm.mongodb.document_manager');
                // DocumentManager にデータを入れて
                $dm->persist($form->getData());
                // 保存
                $dm->flush();

                // リストページにリダイレクト
                return $this->redirect($this->generateUrl('sasayaki_list'));
            }
        }

        return $this->render('SasayakiBundle:Sasayaki:sasayakiform.twig', array(
            'form' => $form,
            'standalone' => $standalone,
        ));
    }
}

src/Application/SasayakiBundle/Resources/config/routing.yml

では、このコントローラにアクセス出来るようにルーティングを書きます。

sasayaki_list:
    pattern:  /
    defaults: { _controller: SasayakiBundle:Sasayaki:list }

sasayaki_create:
    pattern:  /sasayaku
    defaults: { _controller: SasayakiBundle:Sasayaki:create }

sasayaki_byname:
    pattern: /name/:name
    defaults: { _controller: SasayakiBundle:Sasayaki:findByName }

これで、http://example.com/ で一覧、http://example.com/sasayaku で投稿画面、http://example.com/name/[検索した名前] で特定の人の投稿画面が見られますね。

src/Application/SasayakiBundle/Resources/config/config.yml

Validationが有効になるようにconfig.ymlも書きます。

app.config:
    validation:
        enabled: true

src/Application/SasayakiBundle/Resources/config/validation.yml

最低限のValidationの設定を書きました。

Application\SasayakiBundle\Document\Sasayaki:
    properties:
        name:
            - NotBlank: ~
        body:
            - NotBlank: ~

ビューの作成

ここまでくれば、後はビューの作成のみ。
サンプルなので、最低限の内容を書いていきます。

src/Application/SasayakiBundle/Resources/views/layout.twig

{% extends "::layout.twig" %}

{% block body %}
{% block content %}{% endblock %}
{% endblock %}

src/Application/SasayakiBundle/Resources/views/Sasayaki/index.twig

リストページのテンプレートです。

{% extends "SasayakiBundle::layout.twig" %}

{% block content %}
{# <!--
  一覧ページにも投稿画面が欲しいので、createActionの内容を描画します。
  このフォームは、リストページに組み込まれるため、
  standaloneフラグをfalseにしておきます。
--> #}
{% render "SasayakiBundle:Sasayaki:create" with ['standalone': false] %}

{# <!-- 特定の人のささやきの表示の場合、sasayakinameに人の名前が入ります --> #}
<h2>{{ sasayakiname|default('みんな') }} のささやき</h2>

<div id="list">
{% for item in sasayaki %}
{# <!-- それぞれのささやきを表示 --> #}
  <div class="sasayaki">
    <div class="name">name: <a href="{% path 'sasayaki_byname' with ['name': item.name] %}">{{ item.name }}</a></div>
    <div class="body">{{ item.body }}</div>
    <div class="date">sasayaki at: {{ item.sasayakiAt|date("Y-m-d H:i:s") }}</div>
  </div>
{% endfor %}
</div>
{% endblock %}

src/Application/SasayakiBundle/Resources/views/Sasayaki/sasayakiform.twig

{# <!-- 
  standalone が true（SasayakiBundle:Sasayaki:create に直接アクセス）の場合、
  通常のレイアウトを継承し、
  それ以外の（リストページから呼び出された）場合、form.twig を 継承します。
--> #}
{% extends standalone ? "SasayakiBundle::layout.twig" : "SasayakiBundle:Sasayaki:form.twig" %}

{% block content %}
<div id="sasayakiForm">
<h2>ささやく</h2>

<form action="{% path 'sasayaki_create' %}" method="post">
    {{ form|render }}

    <input type="submit" value="Send!" />
</form>
</div>
{% endblock %}

src/Application/SasayakiBundle/Resources/views/Sasayaki/form.twig

{# フォーム以外には描画しない #}
{% block content %}
{% endblock %}

完成！

というわけで、完成したささやきアプリケーションは下記のようなものになりました。

■一覧画面
　　

■投稿画面
　　

■特定の人の一覧画面
　　

Symfony2 の下準備から始めたため、若干長くなってしまいましたが、MongoDB ODMへのアクセス自体は非常に簡単で、柔軟なアクセスが可能になっていることが分かるかと思います。
MongoDB ODM の機能は、ここでは到底書きつくせないほど多くありますので、ぜひ MongoDB ODM を触っていただけたらと思います。

MongoDBもSymfony2も楽しいよ！

こうやったらいいよ！とか、こうじゃない？とか、そういったツッコミがありましたら、是非、 @madapaja もしくは、コメントで教えてください！

Symfony Advent 2010

Symfony Advent 2010では12月1日から12月24日までを使って日替わりでsymfonyでイイなと思った小さなtipsから内部構造まで迫った解説などをブログ記事にして公開していくイベントです。

日本Symfonyユーザー会
 Symfony アドベントカレンダー2010

※Syfony Advent 2010はsymfony好きな有志で集まったチームです。

「第1回 MongoDB JP ＆ CouchDB JP 合同勉強会 in Tokyo」でMongoDB 地理空間インデックスについてLTしました+

2010-12-13T18:09:12+09:00

昨日（2010/12/12）開催された「第1回 MongoDB JP ＆ CouchDB JP 合同勉強会 in Tokyo」で、MongoDBの地理空間インデックスの紹介をLTとしてやりました。

初LTで緊張しまくってましたが（？）皆様の暖かいまなざしに救われ、なんとか無事に終われました。

勉強会全体の内容については、主催者でもある@doryokujinさんがまとめられた記事をご覧ください。
「第1回 MongoDB JP ＆ CouchDB JP 合同勉強会 in Tokyo」を開催してきました！ - doryokujin's blog

で、地理空間インデックスに関するいくつかの補足と、コピペ用のテキストを書いておきたいと思います。

Geospatial Indexingの速度

昨日、Geospatial Indexingの速度はどうなのか聞かれ、数万件程度のレコードでは（普通のIndexに比べて）重くは感じない、と答えたのですが、気になったのでちゃちゃっと検証してみました。
（簡易的な検証ですので参考程度に）

検証環境

CPU: Xeon 2.26 GHz (4コア)
Memory: 4G
OS: CentOS 5.2
PHP: 5.3.3
MongoDB: 1.7.3

（localhost上での検証。各テストは3回計測し、その平均値を掲載しています）

保存

1,000万件のレコードをインサートした時の結果です。

名前	普通のIndex（ObjectId）	GeoIndex
合計時間（秒）	942.7	1,162.2 (+23%)
秒間に処理された件数（/sec）	10,613.4	8,606.7 (-19%)

※カッコ内は、ObjectIdに比べての増減の比率

GeoIndexについては、あらかじめensureIndexを実行してあります。

ObjectIdと比較すると、保存では2割程度の速度低下が見られました。
これは、内部的にGeoHash化するため、その計算処理が多くを占めていると思われます。

検索

上記で保存したデータ（1,000万件）を、ObjectIdでの検索と、GeoIndexの$near, $nearSphereで検索をそれぞれ10万回した時の結果です。
（findOne で実行）

名前	普通のIndex（ObjectId）	$near	$nearSphere
合計時間（秒）	6.2	8.5 (+37%)	9.3 (+50%)
秒間に処理された件数（/sec）	16,155.4	11,770.8 (-38%)	10,770.8 (-51%)

※カッコ内は、ObjectIdに比べての増減の比率

検索に関しては、ObjectIdと比較し、4〜5割程度の速度低下となりました。
これは、基点のGeoHash処理に加え、GeoHashでの前方一致検索を行った後に、距離計算とソートが行われるためかと思われます。

結論

スライド

MongoDBと位置情報〜地理空間インデックスの紹介

View more presentations from madapaja.

スライド内容の補足と、コピペ用コードたち

地理空間のインデックス、Geospatial Indexingでは、二次元の地理空間情報をキーに検索を行うことが出来ます。
経度・緯度以外の情報を入れることも出来ますが、普通は経度・緯度情報を使うと思います。

Geospatial Index の作成

Indexを作るには、普通のIndexと同じで、コレクションのensureIndexメソッドを使うのですが、Geospatial Index の場合は、2dという文字列を指定します。
ただし、コレクション毎に、一つのGeospatial Indexしか作れません。

db.shopinfo.ensureIndex({
  // loc フィールドに Geospatial Index を張る
  loc : "2d"
});

もちろん、複合Indexとして普通のIndexと同時に指定する事も出来ます。

db.shopinfo.ensureIndex({
  loc : "2d", // Geospatial Index を張る
  category: 1 // 他のフィールドに Indexを張る
});

ちなみに、デフォルトでは、±180のfloat値を受け付けますが、拡張も可能です。

db.shopinfo.ensureIndex({
  loc : "2d", // Geospatial Index を張る
}, { // オプションで拡張もできる
  min: -1000,
  max: 1000
});

保存

var lon = 139;
var lat = 35;

db.shopinfo.save({
  name: '喫茶もんご',
  category: ['喫茶店'],
  loc: [lon, lat] // 位置情報 (x, y の順がオススメ)
  // loc: [x: lon, y: lat] // 連想配列でも
  // loc: [lon: lon, lat: lat] // lon,latでも
  // loc: [foo: lon, bar:lat] // 適当な名前でもOK
});

クエリー：完全一致

// ほぼ使い道なし。。。
db.shopinfo.find({
  loc: [139, 35]
});

クエリー：$near

db.shopinfo.find({
  loc : {
    $near : [139.4, 35.4] // [139.4, 35.4]から近い順にソート
  }
});

クエリー：$maxDistance

db.shopinfo.find({
  loc : {
    $near : [139.4, 35.4],
    $maxDistance : 2 // 最大距離が ±2 のものを検索
  }
});

クエリー：複合条件

db.shopinfo.find({
  loc : {
    $near : [139.4, 35.4],
    $maxDistance : 2
  },
  category: '喫茶店'
});

クエリー：geoNearコマンド

geoNearコマンドを使うと、詳細情報を取得することが出来ます。
runCommandメソッドで、geoNearでコレクション名を指定します。
指定出来るオプションには、"near", "maxDistance", "query"なんかがあります。

db.runCommand({
  geoNear: "shopinfo",
  near: [139.4, 35.4],
  maxDistance: 2,
  query: {category: '喫茶店'} // 普通のクエリも使える
});

上記を実行すると下記のように返ってきます

{
  "ns" : "test.shopinfo",
  // ↓基点に指定した情報をGeoHash化したビット列
  "near" : "1110100101001011000011000101000010111011111111011110",
  "results" : [{
    "dis" : 0.5656861498877501, // 距離（単位：度）
    "obj" : {
      "_id" : ObjectId("4d01f5616919cb54afce6a77"),
      "name" : "喫茶もんご",
      "category" : ["喫茶店"],
      "loc" : [139, 35]
    }
  }],
  "stats" : {
    "time" : 0,
    "btreelocs" : 0,
    "nscanned" : 1,
    "objectsLoaded" : 1,
    "avgDistance" : 0.5656861498877501,
    "maxDistance" : 0.5656861498877501
  },
  "ok" : 1
}

地理空間インデックスでは、内部でGeoHashを併用することで、高速性を高めています。

領域のクエリー：$within

長方形のモデルの場合、右上と左下（もちろん、右下と左上とかでもいいのだけど…）の点情報を配列で指定します。

db.shopinfo.find({
  loc : {
    $within : {
      $box : [[130, 30], [140, 35]] // (130, 30) - (140, 35)の長方形内
    }
  }
});

円形のモデルの場合、中心点と半径情報を配列で指定します。

db.shopinfo.find({
  loc : {
    $within : {
      $center : [[135, 35], 4] // (135, 35)から半径4の円の範囲
    }
  }
});

地球は球体：Sphere クエリ

（本当は楕円だ、とか、そういうツッコミはとりあえず置いておきます！）

経度1度の距離は赤道から離れるほど、小さくなるので、精度が落ちてしまう、
というか、ソートの順番が正しくない場合があり、使い物になりません。

Ver.1.7.0以降でサポートされたSphereクエリ使いましょう。

使い方は、$near の代わりに $nearSphere

db.shopinfo.find({
  loc : {
    $nearSphere : [139.4, 35.4]
  }
});

$center の代わりに $centerSphere

db.shopinfo.find({
  loc : {
    $within : {
      // (135, 35)から半径 0.1ラジアンの円の範囲
      $centerSphere : [[135, 35], 0.1]
    }
  }
});

を使うだけ（簡単！）

ちなみに、$boxSphereというのは、仕組み上意味をなさないので無いよ！

Sphere系の距離単位：ラジアン

Sphere系では、距離の単位がラジアンになります。

地球では1ラジアンが6371kmになるので、これを基に計算を行えば問題ないと思います。

1ラジアン = (約) 6371 km

runCommandでの球体モデル

runCommandで、球体モデルを使用したい場合は、spherical パラメータを true にします。

db.runCommand({
  geoNear: "shopinfo",
  near: [135, 35],
  query: {category: '喫茶店'},
  spherical: true // 球体モデルを有効に
});

結果はこんな感じ（抜粋）

"results" : [{
  "dis" : 0.05718377899700883, // ラジアン単位で返ります
  "obj" : {
    "loc" : [139, 35]
  }
}],

検索基点から検索結果までの距離がdisというプロパティで返ってくる（ラジアン単位）ので、上記の場合、0.057…ラジアン×6371kmで、大体364 km になるよ。

というわけで、一緒にMongoDBで遊び（？）ましょう！

MongoDBの地理空間のインデックスを試してみる

2010-11-19T19:31:51+09:00

MongoDB面白いですね。
ドキュメントが親切なのでありがたいのですが、なかなか日本語の記事が無かったりするので、Geospatial Indexingについて試してみた事を投稿しますよ！

マニュアル：MongoDB internal corp site

Geospatial Indexing は MongoDB ver1.3.3以上で使えます。

地理空間のインデックスとは

読んで字のごとくなのですが、MongoDBでは二次元地理空間情報（多くの場合、緯度経度情報）をインデックスとして検索をかけることが出来ます。

最近のガラケーやスマートフォンからは簡単にGPS機能を利用することもできますし、PCブラウザなどでも位置情報を取得出来るようになったり、html5のGeolocation API（厳密にはHTML5に含まれてはいない）の登場などで、今後、ますます位置情報の利用頻度は高くなるんじゃないかと思います。

でも、位置情報って検索が面倒だったりして、そのままで使いやすい情報ではないです。

GeoHashやGeoHexなどというエリア（面）情報として文字列で保存する方法などもありますが、一長一短。

例えば、GeoHashは、文字数が長いほど詳細なエリアを表し、検索なども非常に使い勝手がいい（文字列比較で済む）のですが、その特徴上、距離でのソートが難しかったり、検索エリアの範囲を細かく指定しづらかったりと、デメリットもあります。

どんな技術も、制約と利便性のトレードオフなので、上手く使い分けてやる必要があります。

今回は、MongoDB の Geospatial Index を用いて「近い店検索」のようなものを実験してみます。

データの追加

今回は、テスト用なので渋谷付近にランダムなデータを100件ほど追加します。

以下はmongoシェルでの操作です。

// geotest というDBを使います
use geotest

// 渋谷付近の経度緯度
var baseLng = 139.65534000898916;
var baseLat = 35.63588652257869;
var diffLng = 139.75730686689930 - baseLng;
var diffLat = 35.67661462940957 - baseLat;

// カテゴリのリスト
var categories = ['カフェ', 'バー', 'レストラン'];

// ランダムに100件のデータを追加
for (var i=1; i<=100; i++) {
  var myLng = baseLng + (Math.random() * diffLng);
  var myLat = baseLat + (Math.random() * diffLat);

  var myCategory = categories[
    Math.floor(Math.random() * categories.length)
  ];

  // ランダムなデータを保存
  db.places.save({
    location: [myLng, myLat], // 位置情報
    category: myCategory      // カテゴリ
  });
}

shell で JavaScript が利用できるのは幸せですね。
ランダムデータの生成も楽ちんです。

Index を作成

次に、地理空間インデックスを作成します。

MongoDB では複合インデックスもOKなので、位置情報と共に、カテゴリ情報にもインデックスを張ります。

// インデックスを作成
db.places.ensureIndex({
  location : "2d", // location に Geospatial Index を張る
  category : 1     // category に Index を張る
});

検索してみる

完全一致で検索

db.places.find({ location : [139.66, 35.65] });

普通のインデックスで検索

db.places.find({ category : "レストラン" });

$near で検索

これだと、あまり意味がないのですが、$nearを使う事で、近いロケーションを検索することができます。
（実際には近い順に並び替えられる）

// [139.66, 35.65] の近くにある店を5件検索
db.places.find({ location : { $near : [139.66, 35.65] } }).limit(5);

もちろん、複合インデックスでの指定もOKです。

// [139.66, 35.65] の近くにあるカフェを5件検索
db.places.find({
  location : { $near : [139.66, 35.65] },
  category : "カフェ" }).limit(5);

$nearの注意点

$near は経度と緯度の1度が同じ距離を指すことを前提として計算が行われます。

例えば、

【基点】
経度：10°
緯度：-84°

から、

【点A】
経度：12°
緯度：-84°

【点B】
経度：10°
緯度：-85°

への距離を計算した場合、経度と緯度の1度が同じ距離である平面とすると、下図のような感じになるため、点Bの方が近いように見えます。

実験してみましょう。

// 点A の追加
db.places.save({
  location: [12, -84], name: 'A'
});

// 点B の追加
db.places.save({
  location: [10, -85], name: 'B'
});

// 基点から近いポイントの検索
db.places.findOne({
  location: {
    '$near': [10, -84]
  }
});

結果は下記のように点Aが返ります。

{
        "_id" : ObjectId("4cef9fb0a22c7137b609561a"),
        "location" : [
                10,
                -85
        ],
        "name" : "B"
}

ですが。。。。

実際には、地球は球体なので場所によって1度は変わります。

今回の経度・緯度の場合、下記のような間隔になると予想出来ます。

※実際の縮尺ではありません。

下記サイトで、地球を球体として二点間の距離を計算してみましょう。
２地点間の距離と方位角 - 高精度計算サイト

すると、

【基点-点A間の距離】23.270942 km
【基点-点B間の距離】111.319491 km

となり、実際には点Aの方が近い事がわかります。

この問題に解決するため、新しい球体のモデルがバージョン1.7.0で追加されました。

球体モデルを使用して求める

この先の球体モデルは MongoDB ver1.7.0 以上で使えます。

利用は簡単です。$near を $nearSphere に変更するだけです。

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

db.places.findOne({
  location: {
    '$nearSphere': [10, -84]
  }
});

結果は下記のように正しく点Aが返るようになりました。

{
        "_id" : ObjectId("4cef9fada22c7137b6095619"),
        "location" : [
                12,
                -84
        ],
        "name" : "A"
}

なお、球体モデルを使用する場合には、位置情報を X(経度), Y(緯度) の順で使っていると仮定されるため、その順序を守る必要があります。

サンプルプログラム

今回は、GoogleMaps APIを使用してサンプルプログラムを作ってみました。

mongodbとのやり取りは下記のような形でPHPにて行っています。

<?php

$geo = new getGeoInfo();

// 見つける！
$geo->find(array(
    'location' => array(
        '$nearSphere' => array(
            (float) $lng,
            (float) $lat,
        ),
    ),
));

class getGeoInfo
{
    private $mongo;
    private $collection;

    public function __construct()
    {
        // mongodb に接続
        $this->mongo = new Mongo('mongodb://localhost:27077', array('persist' => 'myPersistId'));
        // collection を選択
        $this->collection = $this->mongo->selectDB('geotest201011')->selectCollection('places');
    }

    public function find($query = array(), $limit = null)
    {
        // findを実行して、カーソルを取得
        $cursor = $this->collection->find($query);

        // JSON形式で返す
        echo '[';
        $isFirst = true;
        $i = 1;
        while ($cursor->hasNext()) {
            if (!is_null($limit) && $limit < $i) break;
            $item = $cursor->getNext();
            $exportItem = array(
                'location' => $item['location'],
                'category' => $item['category'],
            );

            echo ($isFirst) ? '' : ', ';
            echo json_encode($exportItem);

            if ($isFirst) {
                $isFirst = false;
            }

            ++$i;
        }
        echo ']';
    }
}

以上、駆け足ですが、MongoDBでの地理空間インデックスのサンプルでした！

色空間メソッドと色のアニメーションを拡張するjQueryプラグインjQuery.iColor ver.1.0 beta

2010-09-21T16:11:18+09:00

色空間メソッドと色のアニメーションを拡張するjQuery プラグイン jQuery.iColor をバージョンアップしました。

バグフィックスのみで、メソッドなども以前と同等になりますので、使い方については、下記エントリを参照してください。

選択範囲のテキストを操作するjQueryプラグインjQuery.selection

2010-09-17T04:15:59+09:00

以下の内容は、古い内容です。
新しい記事で情報を確認してください。
http://blog.madapaja.net/entry/2012/05/09/070500

選択範囲のテキストを操作するためのjQueryプラグイン jQuery.selection を書いたので、アップしました。

IE6やFireFox3.5、Google Chrome 6など主要なブラウザでチェック済みです。

ファイルはこちら

http://jquery-selection.googlecode.com/svn/tags/（URLが間違っていたため訂正しました）
http://code.google.com/p/jquery-selection/downloads/list (圧縮ファイル)

デモはこちら

jQuery.selection - jQuery Plugin DEMO

簡単な説明

: bold;">$.getSelection([mode = 'text']):HTMLドキュメント内の選択されたテキスト/HTMLを取得する
: bold;">getSelection():テキストボックス/エリアの選択されたテキストを取得する
: bold;">replaceSelection(text[, caret = 'keep']):テキストボックス/エリアの選択されたテキストを置換する
: bold;">insertBeforeSelection(text[, caret = 'keep']):テキストボックス/エリアの選択されたテキストの前に文字列を挿入する
: bold;">insertAfterSelection(text[, caret = 'keep']):テキストボックス/エリアの選択されたテキストの後に文字列を挿入する
: bold;">getCaretPos():テキストボックス/エリアの選択範囲を取得する
: bold;">setCaretPos(range):テキストボックス/エリアの選択範囲を設定する

デモも併せてご確認ください。

$.getSelection([mode = 'text'])

HTMLドキュメント内の選択されたテキスト/HTMLを取得する

mode

modeには、'text'もしくは'html'を指定します。
指定しなかった場合は、'text'となります。

返り値

String型で mode に指定した値によって、選択されたテキストか、HTMLテキストが返ります。

getSelection()

テキストボックス/エリアの選択されたテキストを取得する

返り値

String型で選択されたテキストが返ります。

replaceSelection(text[, caret = 'keep'])

テキストボックス/エリアの選択されたテキストを置換する

text

置換後の文字列を指定します。

caret

caretには'keep'か'start'、'end'のいずれかを指定します。
指定しなかった場合は、'keep'となります。

: bold;">keep:選択範囲を保持します。（指定したtextが選択状態となります）
: bold;">start:キャレットを選択範囲の最初に移動します
: bold;">end:キャレットを選択範囲の後ろに移動します

insertBeforeSelection(text[, caret = 'keep'])

テキストボックス/エリアの選択されたテキストの前に文字列を挿入する

text

挿入する文字列を指定します。

caret

caretには'keep'か'start'、'end'のいずれかを指定します。
指定しなかった場合は、'keep'となります。

: bold;">keep:選択範囲を保持します。
: bold;">start:キャレットを選択範囲の最初に移動します
: bold;">end:キャレットを選択範囲の後ろに移動します

insertAfterSelection(text[, caret = 'keep'])

テキストボックス/エリアの選択されたテキストの後に文字列を挿入する

text

挿入する文字列を指定します。

caret

caretには'keep'か'start'、'end'のいずれかを指定します。
指定しなかった場合は、'keep'となります。

: bold;">keep:選択範囲を保持します。
: bold;">start:キャレットを選択範囲の最初に移動します
: bold;">end:キャレットを選択範囲の後ろに移動します

getCaretPos()

テキストボックス/エリアの選択範囲を取得する

返り値

Object型 {start: 選択開始位置, end: 選択終了位置} で選択範囲が返ります。

例

var pos = $('textarea').getCaretPos();
alert(''+ pos.start + ' から ' + pos.end + 'までが選択されています。');

setCaretPos(range)

テキストボックス/エリアの選択範囲を設定する

range

Object型 {start: 選択開始位置, end: 選択終了位置} で選択範囲を指定します。

例

var strLen = $('textarea').val().length; // 文字数を取得

// 全て選択します
$('textarea').setCaretPos({
  start: 0,     // 最初から
  end  : strLen // 最後まで
});

ファイルはこちら

http://jquery-selection.googlecode.com/svn/tags/（URLが間違っていたため訂正しました）
http://code.google.com/p/jquery-selection/downloads/list (圧縮ファイル)

デモはこちら

jQuery.selection - jQuery Plugin DEMO

色空間メソッドと色のアニメーションを拡張するjQueryプラグインiColorを書いた

2010-09-11T04:15:59+09:00

[色空間] - 今日も適当ダイアリーなどで、色空間の変換についての記事を書きましたが、それらを簡単に使えるように、jQuery プラグインとして書き直しました。

まだ、アルファ版なのですが、取り急ぎ公開しておきます。

ファイルはこちら

http://jquery-icolor.googlecode.com/svn/tags/
http://code.google.com/p/jquery-icolor/downloads/list (圧縮ファイル)
~~http://www.weekendphp.com/jQuery/jquery.color.js~~
~~http://www.weekendphp.com/jQuery/jquery.color-min.js~~

デモはこちら

jQuery.iColor - jQueryPlugin DEMO
~~jQuery.iColor - jQueryPlugin DEMO~~

簡単な説明

このプラグインでは、jQueyrに下記3つが拡張されます。

animateの拡張（色のアニメーションが行えます）
getColorメソッドの追加（iColorオブジェクトを返します）
iColorオブジェクト($.iColor)の追加

animateを拡張

jQuery単体ではanimateにて色のアニメーションが行えないのですが、行えるように拡張を行いました。
また、柔軟な指定に対応しました。

対応したプロパティ名は下記の通りです。

color
backgroundColor
borderTopColor
borderRightColor
borderBottomColor
borderLeftColor
outlineColor

値は下記2通りの方法で指定出来ます。

CSS色指定 (※rgba、hsla形式も対応していますが、IEではalpha値は無視されます)
オブジェクト指定

サンプルを見た方がわかりやすいと思います。

$("#test1").animate({
  backgroundColor: 'yellow'
}, 2000);

$("#test2").animate({
  backgroundColor: 
  // オブジェクトとして、一部の値を渡すことも出来ます。
  {
    'h': '+=1080',
    's': '-=0.3',
    'mode': 'HSV'
  }
}, 3000);

$("#test3").animate({
  backgroundColor: 'rgba(255,255,0,0)',
  borderTopColor: 'lightblue',
  borderBottomColor: 'lightblue',
  borderLeftColor: 'lightblue',
  borderRightColor: 'lightblue'
}, 2000);

$("#test4").animate({
  backgroundColor: {
    'r': '-=100',
    'b': 200,
    'a': '+=0.5',
    'mode': 'RGB'
  }
}, 2000);

getColorメソッドの追加

iColor function getColor(attr)

attr にはCSSプロパティ名を指定します。

返り値はiColorオブジェクトとなります。

// iColor オブジェクトが返ります。
color = $('div#test1').getColor('background-color');

// こんな使い方もできます
$('#getColorTest2').text(
  $('div#test1').getColor('background-color') // div#test1の背景色を取得
    .change('h', '+=30') // hue (色相) を +30度 変える
    .getStr() // 色表現文字列を取得
);

iColorオブジェクトの追加

iColorオブジェクトは下記のいずれかにより生成されます。

// A) getColorメソッド
color = $('div#test1').getColor('background-color');

// B) iColorコンストラクタ
// B-1. 引数指定
color = jQuery.iColor(color1, color2, color3, [type = 'RGB']);
color = jQuery.iColor(color1 color2, color3, [alpha], [type = 'RGBA']);

// color1〜3は数値ですが、typeにより取り得る範囲が異なります。
//      R, G, B: 0 〜 255 または 0% 〜 100%
//      H: 0〜360 (角度なので 0 と 360 は同値)
//      S, V, L: 0 〜 1 または 0% 〜 100%
// alpha 値は 0〜1の数値です。
// type は色空間を表し次のいずれかを取ります。
//      'RGB', 'RGBA', 'HSV', 'HSVA', 'HLS', 'HLSA', 'HSL', 'HSLA'

// B-2. 配列指定
color = jQuery.iColor(colorArray, [type = 'RGB'||'RGBA']);
// colorArray は [color1, color2, color3]
// または [color1, color2, color3, alpha] となります。 

// B-3. オブジェクト指定
color = jQuery.iColor(colorArray, [type = 'RGB'||'RGBA']);
// 例： jQuery.iColor({r: 255, g: 255, b: 255}, 'RGB');
//      jQuery.iColor({r: 255, g: 255, b: 255, type: 'RGB'});

// B-4. CSS色表現指定
color = jQuery.iColor(colorStr);
// colorStr は、 blue や #rrggbb、rgb(255,255,0)、hsla(300,10%,50%,1) など

iColorオブジェクトのプロパティ

iColorオブジェクトは下記のプロパティを持ちます。

typeプロパティ

type プロパティは色空間を表し次のいずれかを取ります。
'RGB', 'RGBA', 'HSV', 'HSVA', 'HLS', 'HLSA', 'HSL', 'HSLA'

色要素プロパティ

typeプロパティに応じて、それぞれの色要素プロパティを持ちます。
たとえば、typeがRGBだった場合、r、g、bという3つの色要素プロパティを持つことになります。

iColorオブジェクトのメソッド

iColorオブジェクトは下記のメソッドを持ちます。

string function getStr([format = '#xxx'])

iColorオブジェクトのCSS色表現文字列を返します。

format は下記のいずれかを取ります

#xxx: #fffのような(可能であれば、短い)16進表現でテキストを返します。
#xxxxxx: #ffffffのような6桁の6進表現でテキストを返します。
rgb: rgb(255, 255, 255) または、rgba(255, 255, 255, 1)形式で返します。
rgb%: rgb(100%, 100%, 100%) または、rgba(100%, 100%, 100%, 1)形式で返します。
hsl: hsl(350, 0.5, 1) または、hsla(350, 0.5, 1, 1)形式で返します。

iColor function to(type)

iColor function toRGB()

iColor function toRGBA()

iColor function toHSV()

iColor function toHSVA()

iColor function toHSL()

iColor function toHSLA()

iColor function toHLS()

iColor function toHLSA()

iColorオブジェクトの色空間変換し、新しいiColorオブジェクトを返します。
toXXX 形式は、to('XXX')のショートカットであり、同一の挙動をします。

iColor function change(target, val, mode)

iColorオブジェクトの特定の色要素を変更し、新しいiColorオブジェクトを返します。

target には変更したい色要素名（1文字の文字列）を指定します。

val には、変更したい値(1 や '255' など)、もしくは変化させたい量('+=0.1' や '-=30' など)を指定出来ます。

詳細はデモで確認してください。

ファイルはこちら

デモはこちら

jQuery.iColor - jQueryPlugin DEMO
~~jQuery.iColor - jQueryPlugin DEMO~~

RGB色空間とHLS(HSL, HSI)色空間の相互変換 Javascript版

2010-09-07T15:16:53+09:00

RGB色空間とHSV色空間の相互変換 Javascript版 - 今日も適当ダイアリーで Javascript での RGB と HSV の相互変換処理を書いたので、今度はRGB と HLS（HSL、HSIと呼ばれる事もある）の相互変換をメモ。

HLS色空間については HLS色空間 - Wikipedia などを参照してください。

RGB から HLS色空間へのコンバート

/**
 * RGB を HLS へ変換します
 *
 * @param   {Number}  r         red値   ※ 0〜255 の数値
 * @param   {Number}  g         green値 ※ 0〜255 の数値
 * @param   {Number}  b         blue値  ※ 0〜255 の数値
 * @return  {Object}  {h, l, s} ※ h は 0〜360の数値、l/s は 0〜1 の数値
 */
function RGBtoHLS(r, g, b) {
  var h, // 0..360
      l, s; // 0..1

  // 0..1 に変換
  r = r / 255;
  g = g / 255;
  b = b / 255;
  var max = Math.max(Math.max(r, g), b),
      min = Math.min(Math.min(r, g), b);

  // hue の計算
  if (max == min) {
    h = 0; // 本来は定義されないが、仮に0を代入
  } else if (max == r) {
    h = 60 * (g - b) / (max - min) + 0;
  } else if (max == g) {
    h = (60 * (b - r) / (max - min)) + 120;
  } else {
    h = (60 * (r - g) / (max - min)) + 240;
  }

  while (h < 0) {
    h += 360;
  }

  // Lightness の計算
  l = (max + min) / 2;

  // Saturation の計算
  if (max == min) {
    s = 0;
  } else {
    s = (l < 0.5)
      ? (max - min) / (max + min)
      : (max - min) / (2.0 - max - min);
  }

  return {'h': h, 'l': l, 's': s, 'type': 'HLS'};
}

HLS から RGB色空間へのコンバート

/**
 * HLS を RGB へ変換します
 *
 * @param   {Number}  h         hue値        ※ 0〜360の数値
 * @param   {Number}  l         lightness値  ※ 0〜1 の数値
 * @param   {Number}  s         saturation値 ※ 0〜1 の数値
 * @return  {Object}  {r, g, b} ※ r/g/b は 0〜255 の数値
 */
function HLStoRGB(h, l, s) {
  var r, g, b; // 0..255

  while (h < 0) {
    h += 360;
  }
  h = h % 360;

  // 特別な場合 saturation = 0
  if (s == 0) {
    // → RGB は V に等しい
    l = Math.round(l * 255);
    return {'r': l, 'g': l, 'b': l, 'type': 'RGB'};
  }

  var m2 = (l < 0.5) ? l * (1 + s) : l + s - l * s,
      m1 = l * 2 - m2,
      tmp;

  tmp = h + 120;
  if (tmp > 360) {
    tmp = tmp - 360
  }

  if (tmp < 60) {
    r = (m1 + (m2 - m1) * tmp / 60);
  } else if (tmp < 180) {
    r = m2;
  } else if (tmp < 240) {
    r = m1 + (m2 - m1) * (240 - tmp) / 60;
  } else {
    r = m1;
  }

  tmp = h;
  if (tmp < 60) {
    g = m1 + (m2 - m1) * tmp / 60;
  } else if (tmp < 180) {
    g = m2;
  } else if (tmp < 240) {
    g = m1 + (m2 - m1) * (240 - tmp) / 60;
  } else {
    g = m1;
  }

  tmp = h - 120;
  if (tmp < 0) {
    tmp = tmp + 360
  }
  if (tmp < 60) {
    b = m1 + (m2 - m1) * tmp / 60;
  } else if (tmp < 180) {
    b = m2;
  } else if (tmp < 240) {
    b = m1 + (m2 - m1) * (240 - tmp) / 60;
  } else {
    b = m1;
  }

  return {'r': Math.round(r * 255), 'g': Math.round(g * 255), 'b': Math.round(b * 255), 'type': 'RGB'};
}

ためしてみる

var r = 10, g = 155, b = 200, hls, rgb;
hls = RGBtoHLS(r, g, b);
rgb = HLStoRGB(hls.h, hls.l, hls.s);

alert('R: ' + r + ', G: ' + g + ', B: ' + b + '\n' +
  ' => H : ' + hls.h + ', L: ' + hls.l + ', S: ' + hls.s + '\n' +
  ' => R : ' + rgb.r + ', G: ' + rgb.g + ', B: ' + rgb.b);

RGB色空間とHSV色空間の相互変換 Javascript版

2010-09-03T17:59:01+09:00

RGB色空間とHSV色空間の相互変換 PHP版 - 今日も適当ダイアリーの記事に、「Javascript RGB HSV変換」というキーワード検索で入ってくる方がいらっしゃるようなので、Javascript版も一応掲載しておきます。

HSV色空間については HSV色空間 - Wikipedia を参照してください。
上記Wikipediaに載っている変換式をそのままjavascriptにしただけなので、特に難しい事はしていません。

jQueryのプラグインにすれば、ちょっとした時に使えるかも？と思いましたが、意外に面倒そうなので、書いたらあらためて、このブログで紹介したいと思います。

RGB から HSV色空間へのコンバート

/**
 * RGB配列 を HSV配列 へ変換します
 *
 * @param   {Number}  r         red値   ※ 0〜255 の数値
 * @param   {Number}  g         green値 ※ 0〜255 の数値
 * @param   {Number}  b         blue値  ※ 0〜255 の数値
 * @param   {Boolean} coneModel 円錐モデルにするか
 * @return  {Object}  {h, s, v} ※ h は 0〜360の数値、s/v は 0〜255 の数値
 */
function RGBtoHSV (r, g, b, coneModel) {
  var h, // 0..360
      s, v, // 0..255
      max = Math.max(Math.max(r, g), b),
      min = Math.min(Math.min(r, g), b);

  // hue の計算
  if (max == min) {
    h = 0; // 本来は定義されないが、仮に0を代入
  } else if (max == r) {
    h = 60 * (g - b) / (max - min) + 0;
  } else if (max == g) {
    h = (60 * (b - r) / (max - min)) + 120;
  } else {
    h = (60 * (r - g) / (max - min)) + 240;
  }

  while (h < 0) {
    h += 360;
  }

  // saturation の計算
  if (coneModel) {
    // 円錐モデルの場合
    s = max - min;
  } else {
    s = (max == 0)
      ? 0 // 本来は定義されないが、仮に0を代入
      : (max - min) / max * 255;
  }

  // value の計算
  v = max;

  return {'h': h, 's': s, 'v': v};
}

HSV から RGB色空間へのコンバート

/**
 * HSV配列 を RGB配列 へ変換します
 *
 * @param   {Number}  h         hue値        ※ 0〜360の数値
 * @param   {Number}  s         saturation値 ※ 0〜255 の数値
 * @param   {Number}  v         value値      ※ 0〜255 の数値
 * @return  {Object}  {r, g, b} ※ r/g/b は 0〜255 の数値
 */
function HSVtoRGB (h, s, v) {
  var r, g, b; // 0..255

  while (h < 0) {
    h += 360;
  }

  h = h % 360;

  // 特別な場合 saturation = 0
  if (s == 0) {
    // → RGB は V に等しい
    v = Math.round(v);
    return {'r': v, 'g': v, 'b': v};
  }

  s = s / 255;

  var i = Math.floor(h / 60) % 6,
      f = (h / 60) - i,
      p = v * (1 - s),
      q = v * (1 - f * s),
      t = v * (1 - (1 - f) * s)

  switch (i) {
    case 0 :
      r = v;  g = t;  b = p;  break;
    case 1 :
      r = q;  g = v;  b = p;  break;
    case 2 :
      r = p;  g = v;  b = t;  break;
    case 3 :
      r = p;  g = q;  b = v;  break;
    case 4 :
      r = t;  g = p;  b = v;  break;
    case 5 :
      r = v;  g = p;  b = q;  break;
  }

  return {'r': Math.round(r), 'g': Math.round(g), 'b': Math.round(b)};
}

ためしてみる

var r = 10, g = 155, b = 200, hsv, rgb;
hsv = RGBtoHSV(r, g, b);
rgb = HSVtoRGB(hsv.h, hsv.s, hsv.v);

alert('R: ' + r + ', G: ' + g + ', B: ' + b + '\n' +
  ' => H : ' + hsv.h + ', S: ' + hsv.s + ', V: ' + hsv.v + '\n' +
  ' => R : ' + rgb.r + ', G: ' + rgb.g + ', B: ' + rgb.b);

SlicehostからさくらのVPSへ乗り換えようか

2010-09-02T16:55:53+09:00

趣味利用のサーバーとして、Rackspace Managed Cloud Services—More than just infrastructureを使っているんだけど、VPS（仮想専用サーバ）｜さくらインターネット - 無料お試し実施中に乗り換えようか考えている。
とりあえず、昨日、申し込みをして、さくらのVPSをお試し中。

基本的なスペック（価格も含めて）は、さくらのVPSが上回っているんだけど、ちょっと僕が迷っているのは下記の3点だ。

Slicehostで出来て、さくらのVPSで出来ないこと

（自分が迷っている点のみ）

IPアドレス追加がない(1個だけ): もう1つ(計2つ)欲しいんだよね。。
Slicehostの場合は、追加IPは1個につき $2.0で出来る。
ネームサーバがついてこない: 自分で動かすのはいやだし。さくらのDNSサーバーでできるのかな？（でも、月額がVPSより高い。。。）
Slicehostなら標準でついてくる。
IPアドレスの逆引きができない: Slicehostなら標準でできる。

オプション対応とかでもいいので、してくれたら、はい変えます！って感じなのだけれど。

もうちょっと悩もうと思う。

結局、さくらに移転することになる気もするけど。

パスワード(ランダム)文字列を生成してみる

2010-09-01T16:55:09+09:00

パスワード自動生成のための javascript を書いてみた。

要件

要件は、下記の通りとします。

生成する文字列の文字数を指定できること
生成する文字列に使用する文字リストを指定できること
生成する文字列の文字が重複しないようにするか否かを指定できること

関数定義

関数の定義は以下の通り

パスワード文字列（ランダム文字列）を生成する

@param     {Number}   i 生成する文字列の文字数
@param     {String}   s 生成する文字列に使用する文字リスト
@param     {Boolean}  f 文字が重複しないようにするか否か
@returns   {String}   生成された文字列

素直にforループでまわしてみる

単純に、forループを使ってランダムな文字列を生成してみます。

なお、今回は、一回限り使えればよかったので無名関数で定義してます。（なので、使いきりです）

(function(i,s,f) {
    var p = '';

    for (; i > 0; i--) {
        // 文字リストからランダムに選択
        var j = Math.floor(Math.random() * s.length);

        // 結果文字列に追加
        p += s.charAt(j);

        // 文字を重複させない場合は今回使った文字をリストから削除
        if (f) {
            s = s.substr(0, j) + s.substr(j + 1);
        }
    }

    return p;
})(
    10, // 文字数
    'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789', // 文字リスト
    true); // 文字を重複させない場合はtrue

念のため言っておくと、実際に利用するには、下記のように記述します。

document.getElementById('ターゲットのID').value =
    /* ここに本体のコード */

やっている事は単純で、forループ内で文字リストからランダムな一文字を選択して、それを結果文字列に追加しているだけです。
文字を重複させない場合は、文字リストから今使った文字を削除していく感じですね。

実行例：http://www.weekendphp.com/misc/blog/hatena/ja9/2010-09-01.1.html

圧縮してみる

上記のコードをあーだこーだして、改行やスペースなどを取っ払って、圧縮（？）してみます。

(function(i,s,f){for(var m=Math,p='';i>0;i--){var j=m.floor(m.random()*s.length);p+=s.charAt(j);s=f?s.substr(0,j)+s.substr(j+1):s}return p})(10,'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789',true);

本体部分は140バイトになりました。
もっと短く出来ないかと、別の方法も考えてみます。

こんどは再帰関数にしてみる

再帰関数にすれば、もっと短くなるのでは？と思い、チャレンジしてみます。

今回は、勉強がてら無名関数を再帰してみます。
自分自身は、arguments.calleeで参照できます。

参考：arguments.callee - JavaScript | MDN

(function(i,s,f) {
    var j = Math.floor(Math.random() * s.length); // 文字リストからランダムに選択

    if (i <= 1) {
        return s.charAt(j);
    }

        // 文字を重複させない場合は今回使った文字をリストから削除
    if (f) {
        s = s.substr(0, j) + s.substr(j + 1);
    }

    // i > 1 なら再帰させる
    return s.charAt(j) +
            arguments.callee(i - 1, s, f); // 自分自身を呼び出す
})(
    10, // 文字数
    'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789', // 文字リスト
    true); // 文字を重複させない場合はtrue

やっている事自体は、forの時と大差ありません。

圧縮してみる

あーだこーだします。

(function(i,s,f){var m=Math,j=m.floor(m.random()*s.length);return s.charAt(j)+(i>1?arguments.callee(i-1,f?s.substr(0,j)+s.substr(j+1):s,f):'')})(10,'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789',true);

どうかな？
と思ったら、本体部分は144バイトでした。
forループより4バイト増えてしまいました。

そもそも、arguments.callee という変数/メソッド名が長いので、不利だったぽいです。

また、時間が時間があったら別の方法も考えてみようかな。

RGB色空間とHSV色空間の相互変換 PHP版

2010-08-31T00:24:30+09:00

PHP配列とCSS色表現の相互変換 - 今日も適当ダイアリーに続いて、 relColors に使った関数を公開します。

色の明度や色相を計算するために、いったんRGBで表現された色情報を、HSV色空間に変換した上で計算を行いました。
HSV色空間については HSV色空間 - Wikipedia を参照してください。

RGB から HSV色空間へのコンバート

変換式は、上記したWikipediaに載っているので、それを素直にPHPで書きました。

<?php
/**
 * RGB配列 を HSV配列 へ変換します
 *
 * @param   array   $arr            array(r, g, b) ※ r/g/b は 0〜255 の数値
 * @param   bool    $coneModel      円錐モデルにするか
 * @return  array   array(h, s, v) ※h は 0〜360の数値、s/v は 0〜255 の数値
 */
function RGBtoHSV($arr, $coneModel = false)
{
    $h = 0; // 0..360
    $s = 0; // 0..255
    $v = 0; // 0..255

    $max = max($arr);
    $min = min($arr);

    // hue の計算
    if ($max == $min) {
        $h = 0; // 本来は定義されないが、仮に0を代入
    } else if ($max == $arr[0]) {
        // MAX = R
        // 60 * (G-B)/(MAX-MIN) + 0
        $h = 60 * ($arr[1] - $arr[2]) / ($max - $min) + 0;
    } else if ($max == $arr[1]) {
        // MAX = G
        // 60 * (B-R)/(MAX-MIN) + 120
        $h = (60 * ($arr[2] - $arr[0]) / ($max - $min)) + 120;
    } else {
        // MAX = B
        // 60 * (R-G)/(MAX-MIN) + 240
        $h = (60 * ($arr[0] - $arr[1]) / ($max - $min)) + 240;
    }

    while ($h < 0) {
        $h += 360;
    }

    // saturation の計算
    if ($coneModel) {
        // 円錐モデルの場合
        $s = $max - $min;
    } else {
        if ($max == 0) {
            // 本来は定義されないが、仮に0を代入
            $s = 0;
        } else {
            $s = ($max - $min) / $max * 255;
        }
    }

    // value の計算
    $v = $max;

    return array(
        $h, // H
        $s, // S
        $v, // V
    );
}

HSV から RGB色空間へのコンバート

<?php

/**
 * HSV配列 を RGB配列 へ変換します
 *
 * @param   array   $arr            array(h, s, v) ※h は 0〜360の数値、s/v は 0〜255 の数値
 * @return  array   array(r, g, b) ※ r/g/b は 0〜255 の数値
 */
function HSVtoRGB($arr)
{
    $r = 0; // 0..255
    $g = 0; // 0..255
    $b = 0; // 0..255

    while ($arr[0] < 0) {
      $arr[0] += 360;
    }

    $arr[0] = $arr[0] % 360;

    // 特別な場合
    if ($arr[1] == 0) {
        // S = 0.0
        // → RGB は V に等しい
        return array(
            round($arr[2]),
            round($arr[2]),
            round($arr[2]),
        );
    }

    $arr[1] = $arr[1] / 255;


    // Hi = floor(H/60) mod 6
    $i = floor($arr[0] / 60) % 6;
    // f = H/60 - Hi
    $f = ($arr[0] / 60) - $i;

    // p = V (1 - S)
    $p = $arr[2] * (1 - $arr[1]);
    // q = V (1 - fS)
    $q = $arr[2] * (1 - $f * $arr[1]);
    // t = V (1 - (1 - f) S)
    $t = $arr[2] * (1 - (1 - $f) * $arr[1]);

    switch ($i) {
        case 0 :
            // R = V, G = t, B = p
            $r = $arr[2];
            $g = $t;
            $b = $p;
            break;
        case 1 :
            // R = q, G = V, B = p
            $r = $q;
            $g = $arr[2];
            $b = $p;
            break;
        case 2 :
            // R = p, G = V, B = t
            $r = $p;
            $g = $arr[2];
            $b = $t;
            break;
        case 3 :
            // R = p, G = q, B = V
            $r = $p;
            $g = $q;
            $b = $arr[2];
            break;
        case 4 :
            // R = t, G = p, B = V
            $r = $t;
            $g = $p;
            $b = $arr[2];
            break;
        case 5 :
            // R = V, G = p, B = q
            $r = $arr[2];
            $g = $p;
            $b = $q;
            break;
    }

    return array(
        round($r), // r
        round($g), // g
        round($b), // b
    );
}

DB内のテーブル名一覧、テーブル情報などを取得するSQL

2010-08-30T14:27:38+09:00

PHPで新人教育向けにSQL（ここでは PostgreSQL）勉強用プログラムを制作しているのだけど、その中で、DB内のテーブル名一覧や、テーブル情報、列情報などを表示させたい、と思った。

で、お題を追加や変更時になるべく最小限の変更で済むようにするには……とかそんな事を思ったら、やっぱりDBの事はDBに聞け、って結論に。

始めて pg_* 系のテーブルをあーだこーだして、たどり着いたSQLを（ツッコミどころがありそうで心配なのですが）備忘録代わりに記載しておきます。

テーブル一覧の取得

SELECT
    cls.oid,     -- pg_class.oid
    nsp.nspname, -- テーブルを持つスキーマ名 public とか
    usr.usename, -- 所有ユーザー名
    cls.relname  -- テーブル名
FROM
    pg_class cls
        INNER JOIN pg_namespace nsp
            ON (cls.relnamespace = nsp.oid)
        INNER JOIN pg_user usr
            ON (cls.relowner = usr.usesysid)
WHERE
    cls.relkind = 'r'
--     AND nsp.nspname = 'public' -- スキーマ名で絞込み
--     AND usr.usename = 'user1' -- 所有ユーザー名で絞込み
ORDER BY
    nsp.nspname,
    usr.usename,
    cls.relname

pg_class を基点に、ネームスペースとユーザー情報を取得します。
relkind は種別を表していますが、小文字の r が通常のテーブル、となります。

シーケンス一覧の取得

SELECT
    cls.oid,     -- pg_class.oid
    nsp.nspname, -- シーケンスを持つスキーマ名 public とか
    usr.usename, -- 所有ユーザー名
    cls.relname  -- テーブル名
FROM
    pg_class cls
        INNER JOIN pg_namespace nsp
            ON (cls.relnamespace = nsp.oid)
        INNER JOIN pg_user usr
            ON (cls.relowner = usr.usesysid)
WHERE
    cls.relkind = 'S'
--     nsp.nspname = 'public' -- スキーマ名で絞込み
--     usr.usename = 'user1' -- 所有ユーザー名で絞込み
ORDER BY
    nsp.nspname,
    usr.usename,
    cls.relname

やっている事は、テーブル一覧の取得と全く変わりません。
relkind が大文字の S がシーケンスを表します。

テーブル列一覧の取得

上記テーブル一覧取得の際にゲットした「pg_class.oid」を基に列の一覧を取得します。

SELECT
    colname as "列名",
    CASE
        WHEN size IS NULL
            THEN datatype
        -- サイズ情報が取得できた場合は付加
        ELSE datatype || ' (' || size || ')'
    END AS "データ型",
    CASE
        -- NOT NULL情報 と DEFAULT情報をマージ
        WHEN "notnull" IS NOT NULL AND "default" IS NOT NULL
            THEN "notnull" || ' ' || "default" -- 
        ELSE COALESCE("notnull", "default")
    END AS "属性"
FROM
    (
        SELECT
            attr.attnum AS idx, -- 列番号
            attr.attname AS colname, -- 列名
            CASE typ.typname -- 分かりやすい名前に変更
                WHEN 'int2'   THEN 'SMALLINT'
                WHEN 'int4'   THEN 'INT'
                WHEN 'int8'   THEN 'BIGINT'
                WHEN 'float4' THEN 'REAL'
                WHEN 'float8' THEN 'DOUBLE'
                WHEN 'bpchar' THEN 'CHAR'
                ELSE UPPER(typ.typname)
            END AS datatype, -- データ型
            -- attr.atttypmod が正の整数なら、
            -- サイズ付加情報あり？
            -- （よく調べて無いので自信なし）
            CASE WHEN attr.atttypmod > 0 THEN
                CASE typ.typname
                    WHEN 'numeric'
                        THEN (attr.atttypmod - 4) / 65536
                    WHEN 'decimal'
                        THEN (attr.atttypmod - 4) / 65536
                    WHEN 'date'
                        THEN COALESCE(attr.atttypmod - 4, 10)
                    WHEN 'time'
                        THEN COALESCE(attr.atttypmod - 4, 8)
                    WHEN 'timestamp'
                        THEN COALESCE(attr.atttypmod - 4, 19)
                    ELSE attr.atttypmod - 4
                END
            END AS size,
            -- attnotnull が true なら NOT NULL
            CASE attr.attnotnull
                WHEN TRUE THEN 'NOT NULL'
                ELSE NULL
            END AS notnull,
            -- atthasdef が true なら DEFAULT 値あり
            CASE attr.atthasdef
                WHEN TRUE THEN 'DEFAULT ' || adef.adsrc
                ELSE NULL
            END AS default
        FROM
            pg_class cls
                INNER JOIN pg_attribute attr
                    ON (cls.oid = attr.attrelid)
                INNER JOIN pg_type typ
                    ON (attr.atttypid = typ.oid)
                -- デフォルト値情報
                LEFT OUTER JOIN pg_attrdef adef
                    ON (cls.oid = adef.adrelid
                        AND attr.attnum = adef.adnum)
        WHERE
            cls.oid = ? -- pg_class.oid を入れよ
            -- 列番号が0以下の場合、システム列なので対象にしない
            AND attr.attnum >= 0
            -- attisdropped が TRUE なら、
            -- この列はすでに削除されていて無効状態
            AND attr.attisdropped IS NOT TRUE
            AND typ.typisdefined
    ) AS tbl
ORDER BY idx;

メジャーどころの型でしか試してないし、複合型などの事は一切考えずに書いているので、問題があるかもしれません。
特にサイズ情報の取得は自信がない（＝適当）です。
必要があったら、また調べて書き直したいと思います。
というか、コメントで教えていただけると助かります。（自堕落ですみません）

テーブルインデックスの取得

「pg_class.oid」を基にテーブルインデックス情報を取得します。

SELECT
    cls.relname AS name, -- インデックス名
    (
        CASE
            -- プライマリキー
            WHEN idx.indisprimary
                THEN 'PRIMARY KEY, '
            -- ユニーク属性
            WHEN idx.indisunique
                THEN 'UNIQUE, '
        END
        || am.amname -- インデックスのアクセスメソッド名
        || ' ('
        -- 列名の取得（カンマ区切りで並べる）
        || ARRAY_TO_STRING(ARRAY(
            SELECT
                attr.attname
            FROM
                pg_class cls2
                    INNER JOIN pg_attribute attr
                        ON (cls2.oid = attr.attrelid)
            WHERE
                cls2.oid = idx.indrelid
                AND attr.attnum = ANY(idx.indkey)
        ), ', ')
        || ')'
    )AS value -- 情報
FROM
    pg_index idx
        INNER JOIN pg_class cls
            ON (idx.indexrelid = cls.oid)
        INNER JOIN pg_am am
            ON (cls.relam = am.oid)
WHERE
    idx.indrelid = ? -- pg_class.oid を入れよ
ORDER BY
    indexrelid;

テーブルチェック制約 / 外部キー制約の取得

「pg_class.oid」を基にチェック制約 / 外部キー制約を取得します。

SELECT
    con.conname AS name, -- 制約名
    pg_get_constraintdef(con.oid) AS value -- 情報
FROM
    pg_constraint con
WHERE
    con.conrelid = ? -- pg_class.oid を入れよ
    AND (con.contype = 'c' OR con.contype = 'f')
ORDER BY
    con.contype,
    conname;

テーブルトリガの取得

「pg_class.oid」を基にテーブルトリガ名、実行する関数情報を取得します。

SELECT
    trg.tgname, -- トリガ名
    prc.proname, -- 実行する関数名
    rtrim(replace(encode(trg.tgargs, 'escape')
        , E'\\000', ', '),', ') -- 引数
FROM
    pg_trigger trg
    INNER JOIN pg_proc prc ON (trg.tgfoid = prc.oid)
WHERE
    trg.tgrelid = 17812 -- pg_class.oid を入れよ
    AND trg.tgenabled
    AND trg.tgisconstraint IS FALSE

トリガが実行されるタイミングは取得していません。
（面倒そうだったので、機会があれば調べてみようと思います。）

間違い、過不足、他のいい方法などありましたら、コメントで教えてください。
よろしくお願いします。

PHP配列とCSS色表現の相互変換

2010-08-28T12:08:28+09:00

前回（色をアルファブレンドする - 今日も適当ダイアリー）にて、 relColors に使った使い回せそうな関数の公開を始めたのですが、ユーティリティ関数を書くのをすっかり忘れていました。

ということで、色テキスト表現からPHP配列の相互変換の関数を提示しておきます。

たいした事してないですけどね。
PHPで16進数テキストを integer にしたい場合は hexdec を使うとか、integer から16進表現にする場合は sprintf を使うとか、そこあたりは、よく忘れますよね。
初めてこの関数を聞いたっていう方は、頭の片隅においておくと、何かの時に便利かもと思います。

<?php

/**
 * 色表現テキスト(#rrggbb 形式) を配列形式に変換します
 *
 * @param   string  $str        色表現テキスト(#rrggbb 形式)
 * @return  array   array(r, g, b)
 */
function getColor($str)
{
    // 先頭の # を除去 (#rrggbb → rrggbb)
    if (strpos($str, '#') === 0) {
        $str = substr($str, 1);
    }

    // 先頭の 0x を除去 (0xrrggbb → rrggbb)
    if (strpos($str, '0x') === 0) {
        $str = substr($str, 2);
    }

    // 6 桁にそろえる
    switch (strlen($str)) {
        case 6:
            // 6桁ならそのまま
            break;
        case 3:
            // 3桁なら6桁に (rgb → rrggbb)
            $str = $str[0] . $str[0] . $str[1] . $str[1] . $str[2] . $str[2];
            break;
        default:
            // それ以外はNG
            return false;
    }

    $matches = array();
    // rrggbb を色事にキャプチャ
    if (preg_match('/^([0-9a-f]{2})([0-9a-f]{2})([0-9a-f]{2})$/i', $str, $matches) != 1) {
        // rrggbb (それぞれは0~9 か a〜f) 以外ならNG
        return false;
    }

    return array(
        hexdec('0x' . $matches[1]), // (int) r
        hexdec('0x' . $matches[2]), // (int) g
        hexdec('0x' . $matches[3]), // (int) b
    );
}

/**
 * 配列形式 を 色表現テキスト(#rrggbb 形式) に変換します
 *
 * @param   array   $arr        array(r, g, b)
 * @param   bool    $compress   短い色表現(#rgb 形式) を許すか
 * @param   string  $prefix     プレフィックス (# 以外にしたい場合は指定)
 * @return  string  色表現テキスト(#rrggbb 形式)
 */
function getText($arr, $compress = true, $prefix = '#')
{
    // マイナス値が入っていたらNG
    if (min($arr) < 0) {
        return false;
    }

    // rrggbb 形式に変換 (integer 型に強制しておく)
    $tmp = sprintf('%02x%02x%02x', (int) $arr[0], (int) $arr[1], (int) $arr[2]);

    // 6桁にならない場合は失敗 (256以上が入っているとそうなる)
    if (strlen($tmp) !== 6) {
        return false;
    }

    // 短い色表現を許す場合で、
    // rr/gg/bb のそれぞれの上位と下位が同一であれば
    if ($compress
            && $tmp[0] == $tmp[1]
            && $tmp[2] == $tmp[3]
            && $tmp[4] == $tmp[5]) {
        // 3桁(rgb)にする
        $tmp = $tmp[0] . $tmp[2] . $tmp[4];
    }

    return $prefix . $tmp;
}

こんなもんです。

今日も適当ダイアリー

第89回PHP勉強会＠東京でBEAR.Sundayのお話をしてきました #phpstudy

BEAR.Sundayのはなし

BEAR.Sunday = DI + AOP + REST(Hypermedia)

DI と Ray.Di

AOP と Ray.Aop

REST(Hypermedia) と ROP（リソース指向プログラミング）、BEAR.Resource

まとめ

質問

BEAR.Sunday の由来は何ですか？

どの程度の規模のアプリに適していますか？

参考URL

BEAR.Sunday meetup #0 でRayについて話してきました #BEARSunday

Ray.Di / Ray.Aop コトハジメ

BEAR.Sunday

Ray (rayphp)

Ray.Di

Symfony DI and Ray.Di Pattern A

Ray.Di Pattern B (BEAR.Sunday standard, DI with annotation)

モジュール

Ray.Aop

まとめ

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻 其の参

前回の補足

@PostConstruct アノテーション

モジュールの作り方について

すべてのメソッドにインターセプタをバインドしてみる

アノテーションを使って特定のメソッドにインターセプタをバインドしてみる

参考リンク

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻 其の弐

Ray を使わずに書いてみる

Ray.Di でインジェクトしてみよう

アノテーションの追加

UserModule を作る

インジェクタ経由でインスタンスを取得する

アノテーションのオートロードを設定

@PostConstruct アノテーションによる初期化メソッドの定義

いよいよ Ray.Aop の登板！

参考リンク

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻 其の壱

Rayって何?

RayをComposerでインストール

書き始める

ここからRayの出番です

参考リンク

Symfony勉強会 #6 に参加してきた〜Symfony温泉に向けて

Symfony温泉？

勉強会レポート

選択範囲のテキストを操作する jQuery.selection を更新して github に移行しました

jQuery.selection とは

変更点

リンク

PHP5.4 で Symfony2 は速くなるのか？

いざ、テスト！

PHP 5.4.0RC2 で謎のセグフォ

PHP5.4+ で開発が行われている BEAR.Sunday フレームワークを動かしてみる

ビルトインウェブサーバー対応

Trait によるページ単位でのテンプレートエンジン選択

2.0 からはじめる MongoDB - 第1回 #mongodbjp

今回のアジェンダ

なぜ MongoDB か

MongoDB のインストール

Mac OS X へのインストール

Linux へのインストール

CentOS / Fedora へのインストール

Ubuntu へのインストール

Windows へのインストール

データディレクトリの作成

サービスとして登録する

MongoDB シェルと戯れる

MongoDB シェルの起動と終了

MongoDB シェルの特徴

まとめ

MongoDB の歴史（MongoDB 2.0 まで） #mongodbjp

～2008年

2009年

バージョン 1.0

バージョン 1.2

新機能

アップグレードの注意点

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻其の参

`@PostConstruct` アノテーション

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻其の弐

PHP5.4+フレームワーク BEAR.Sundayを理解するためにRay.Diを触ってみるの巻其の壱