BEAR Blog

Because everything is a resource.

「全てを結ぶ力」フィードバック

| Comments

今回のPHPカンファレンス関西の基調講演を大変楽しみにしてくれていた方々がいて、遠方から来てくれた人(東京、名古屋、岐阜、福岡などなど)に「基調講演を楽しみに来た」と声をかけてもらいました。

そして講演直後にはphpnwの時のように沢山の方々が次々に来てくれて感想を伝えてくれました。Twitterやブログにも沢山の感想を頂いたので、講演をした記念になるようにフィードバックを集めてみました。(もしここにないのがあれば教えてください)

こんなフィードバックは受けた事ないだけでなく見た事もありません。ありがとうございます。

終了直後

当日午後 – 夜

翌々日のブログ公開

映画化!?

週明け

ブログ

“郡山さんによる基調講演は、世界中の開発者と力を合わせる楽しさ また、開発者としてWeb創造に関わる喜びを実感できる内容でした。”

http://ogom.github.io/2014/06/28/phpconfkansai2014.html

“基調講演を聴きに行ったわけですが、非常にすばらしかったです。”

http://blog.a-way-out.net/blog/2014/06/30/php-conference-kansai-2014/

“基調講演の中で特に興味深かったものは、海外でのお話”

http://pneskin2.nekoget.com/press/?p=1374 (NEKOGET PRESS)

コメント

“歴史の流れ、技術の変遷、人のつながり、そのすべてが結ばれた結果として、今身の回りにあるすべてと自分。 … 講演に注がれたパワーの強さ、込められた思いの大きさも、ひしひしと伝わりました。 そして最後のスライド、あのさまざまなものがつながって光っている絵が強く印象に残りました。”

http://koriym.github.io/blog/2014/06/29/phpkansai2014/#comment-1461173703 (@hidenorigoto)

“お話の内容は多岐に渡り、でも一貫したトーンがあって、とても楽しかったです!

http://koriym.github.io/blog/2014/06/29/phpkansai2014/#comment-1461511490 (@kuma_nana)

基調講演「全てを結ぶ力」

| Comments

PHPカンファレンス関西で基調講演の機会をいただく事ができました。私のタイトルは「全てを結ぶ力」というもので、結ぶ(ハイパーリンク)という原則を持つWWWとそれに関わる技術や私たち開発者の話しをしました。

国内外含めてカンファレンスに登壇するのはこれが二度目です。最初のカンファレンスは世界レベルのエンジニア達をインスパイアさせたいという 夢を持ち、最上級のカテゴリで応募しました。二回目の今回は基調講演として聴衆者を限定しないで多くの人々に話がしたいと思いました。

2014/06/28 10:30 AM 大阪産業創造館

最小のネットーワーク


最大のネットワーク


最初のウェブサイト


最初のPHP


最初のアプリケーションサーバー



最初のつぶやき


決意


インターネットの原則


ソフトウエアの背後にいる人々


私たち開発者


メディアシフト


エピローグ

情報という宇宙でWebサイトという星を1つ作る。それは25年前に考えられたアルファベット最初の文字のタグで繋がれている。Webという力が世界の知識を結び、オープンソースやコミュニティが私たち開発者を結んでいる。またその私たちも技術を結び、Web創造の歴史に参加している。

謝辞

4度をリハーサルを行いました。協力してくれたビットノーツ、エキサイト、HubTokyoのメンバー、その他の方々ありがとうございました。 タイトルをぎりぎりまで決める事が出来ず、PHPカンファレンス関西の運営の方々にも心配かけました。色々お世話になりました。

講演も無事終わりほっとしてます。Twitterでも多くの方が講演に関してつぶやいてくれてるのを見ました。 聞いてくださったみなさん、本当にありがとうございました。

PHPNW2013(3)-Feedback

| Comments

フィードバック

joind.in

joind.inでは人によるチェックで選ばれたカンファレンスが登録されていて、トークのフィードバックを得る事ができます。 国内ではトーク後の聴衆からの反応はねぎらいの言葉や感謝の言葉が多く、もし不満足な場合でも特にそれを表明しない事が多いと思います。

joind.inでは良いトークは賞賛される一方、良くないと評価されたものには(時に非常に)厳しい言葉が並び★評価が低いものになります。トークは「批評」されるのです。

賞賛の言葉が並べば自分の訴えた事が伝わり肯定された事が分かるし、厳しい言葉が並んだとしてもそれを改善に活かす事ができます。 ★の数ではなく「何故聴衆はそう感じたか」を知る事ができるのは役に立ちます。

自分のトークは「今求められているもの」ではなく新しいアイデアです。フィードバックをもらえる仕組みがあるというのは、批評される恐さがある一方でありがたい事だとも思いました。

トーク終わった後、当日、次の日とポツポツとレビューがあがります。


https://joind.in/9302

ネガティブな評価は言葉の事でした。しかし心配してた自分の英語ではなくて日本語=英語の同時通訳を途中に入れた事でした。 地元のユーザーグループとBBCと二回のリハーサルで問題ないとフィードバックをもらってたのでこれは意外な事でした。人によって感じ方がかなり違うのかもしれません。

その点を除けばアイデアや問題解決のためのアプローチを肯定する良い評価が並びました。

“A novel presentation”, “Love the passion”, “A really inspiring”, “Mind-blowing bunch of ideas”。最上級の言葉が並びました。 プレゼンテーションは成功したのです!!

Twitter

Twitterでも頂きました。

中でも気に入ってるのはこの「looks crazy! 」です。

Blog

いくつかのブログでもフィードバックを頂けました。

it does show us how it is possible to think about the web service process and how we might approach it a little differently.

I thought it was about something completely different. It introduced Aspect oriented programming (something I had only seen in other languages, and had not considered using with PHP). The speaker was from Japan and had a guy interpreting for him at times. It should have been a disaster, but was not. It was interesting.

I spoke a lot to Akihito Koriyama, who wrote a framework called BEAR, which breaks a lot of the principles that the popular frameworks follow. It does this in a way that improves the object-oriented structure of the application from more traditional architectures.

This talk introduced the “BEAR.Sunday” framework, which took a new, Eastern-thinking approach to PHP frameworks.

Leeds

Leedsのときのもありました。

直接のフィードバック

終わった直後やその後にも、多くの人が自分の元に来てくれ感想を伝えてくれたり、質問をくれました。中には自分がいつもブログを読んでる知っている方もいました。 驚いたのは会場で話を聞いてなかった人まで来たことです。(トークは同時に3つあります)「聞き逃したんだけど友達からすごくインスパイアされたって聞いた。ちょっと聞かせてくれる?」こういう人が何人も現れました。 phpnwは参加者同士が交流できる多くの時間が用意されています。

帰りの電車で

カンファレンスは3日間ありますが、外国から飛行機で来ている人もいてお昼には終わります。会場を後にし電車に乗っていると、向こうからこちらをチラチラ見てる人がいます。カンファレンスでスピーカーギフトとしてもらったトレーナーを来ていたのですが、それを見てたのです。 「あなたもしかしてphpnwでフレームワークの話をした人?」ビックリしました!!彼の会社はカンファレンスの大手スポンサーだけど今年は自分はいけなかった。しかし同僚に話を聞いてたというのです。彼は興奮してましたが、僕はそれ以上。電車が目的地に着くまで話は尽きませんでした。

初めてのプレゼンテーションでした

meetupやSymfony勉強会で部分的な紹介をした事はありますが、BEAR.Sundayフレームワークの全体のプレゼンテーションを行ったのは国内含めてこれが初めてでした。 「インスピレーションを与える」という目的は達成できました。フィードバックをもらえたおかげで、会場に大勢の人が集まったのも、大きな拍手をもらったのも、遠い国から来てプレゼンテーションをしている人への暖かい応援というだけではなくその内容が評価されたのだと思う事ができました。

共同発表者のリチャードさんと相談を重ね、長い時間をかけ資料を準備しました。イギリスについてからも直前まで手直しを続けました。子供たちにもスピーチを聞いてもらって何度も練習を重ねました。 そうやって準備や練習にもとてつもないエネルギーをそそいだ成果でした。

リチャードさんありがとうございました。本当に面白かったです!

phpnw13 blog entries

http://www.boxuk.com/php-north-west-2013 http://www.labelmedia.co.uk/blog/phpnw13.html http://blogs.edgehill.ac.uk/webservices/2008/11/30/php-north-west-conference-review/ http://www.justanothermark.co.uk/blog/2013/php-north-west-2013 http://www.ctidigital.com/blog/development/phpnw13-guzzle-coding-standards-dependency-injection http://www.hashbangcode.com/blog/phpnw13-review

※ 来週末の6月28日(土)にPHPカンファレンス関西で「全てを結ぶ力」というタイトルで講演を行います。PHPカンファレンス関西はこれが初めてです。よろしくお願いいたします!

TEDxTokyo 2014

| Comments

Connecting the unconnected

2014 5/31 (土) 9:00 – 18:00

5月31日にヒカリエで開かれたTEDxTokyo 2014でオーディエンスとして参加する機会をいただきました。 去年に続いて二度目です。

“25年以上前にカンファレンスとして始まりましたが、素晴らしい考えやアイデアを識別し広める幅広いプラットフォームへと進化しました。”

ビデオにあるように「素晴らしい考えやアイデアを識別し広める幅広いプラットフォーム」それがTEDです。 TEDxTokyoはその精神を引き継いだ米国以外では初めてのTEDxイベントです。

“様々な分野で活躍する参加者が招待され一日かけて各々の考えを他の参加者と共有します。また、その中の一部の人たちは講演を行うことにもなっています。…主なTEDカンファレンスと同じく、講演者と参加者の区別はほとんどありません。”

http://www.tedxtokyo.com/about-tedxtokyo/faq/#sthash.gIvI16UN.dpuf

参加者は単にプレゼンテーションを生で観られるというだけではありません。分野の違う人達が集まり、素晴らしい考えやアイデア (Ideas worth spreading)を共有するのです。

セッションは4つに分かれます。Unconnected、Making Patters、Seeking Synchronicityそれに Connnectedとそれぞれ名付けられたセッションは6-8つのプレゼンテーションを持ちます。最大18分の凝縮されたプレゼンテーションはそのうちの1つだけを見ても強く印象に残るものですがそれが30近くもあるのです!まさに知の渦にダイブです。

一番最初のプレゼンテーションは米国で活動する書家アーティストの山口 碧生さん、今年のテーマ「Connecting the Unconnected」その「結」を特大の筆で書き上げ、それを壁に掲げます。パフォーマンスと音楽を融合した彼女の”書”は迫力のあるものです。

しかし同時に自分たち=ここに集まった大勢の人が見ているのは「文字を一文字書く」それだけの事という事にも気付きます。それが百の言葉より説得力を持ち、力となり、見ている人達の熱狂を誘うのです。今年のTEDxTokyoのテーマを1文字で書き上げる素晴らしいオープニングになったと感じました。

去年最初のパフォーマンスは手妻師の藤山晃太郎さんの江戸古典奇術の「手妻」でまるで何かの魔法を見てるようでしたが、今年も違った魔法が最初のプレゼンテーションとなりました。

マリアン・グッデル

「バーニングマン」は8月1週間だけネバダの砂漠に都市「ブラック・ロック・シティ」が現れる奇跡のようなイベントです。数年前に参加した友人の写真で度肝を抜かれました。

そのバーニングマンのオーガナイザー、マリアン・グッデルが次のプレゼンテーションを行いました。

聞きながら’01年の武尊祭を思い出し、あの頃のパーティーカルチャーもこのバーニングマンの十大原則のいくつかを共有してるのではと思いました。優れた原則や理念を持ったコミュニティは特別なコミニュケーションを生み出します。バーニングマン、TED、TEDx、独創的なオーガナイザーによって開かれた幾多のパーティー、みな共通するものがあるのではないでしょうか。

情熱

多くのプレゼンテーションの中でも特に印象に残ったのがこの2つです。

経営学者の石倉 洋子さんのスピーチは非常にパーソナルな内容で、自分の半生をカイトに見立て、時に舞い上がり、時に逆風にさらされる様を静かに熱く語ります。

フォトグラファーのレスリー・キーさんは世界的名声を得た今も青年の時の気持ちをずっと胸にいだき、それを大切にしてきたか、それが伝わる情熱に満ちたものでした。

そうなのです、”知の渦にダイブ”のTEDxで強く心に残るのは、自らが求める課題に対峙するその真摯な姿勢なのです。 語られる「広める価値のある」優れたアイデアは頭に脳に強く作用するのですが、それを語る人達の精神性や人間性に心が打たれるのです。

前回は特に田子 學さんと坂 茂さんのスピーチがそうでした。田子さんは今回オーディエンスとして参加されていて、去年のスピーチの感想や印象を伝える事ができました。嬉しくて「講演者と参加者の区別はほとんどありません」のTEDxの理念はどこかに飛んでいきスターにあったファンのように興奮し(コーヒーをこぼすぐらい!)田子さんのスピーチがいかにその後に影響を与え、ずっと印象に残ってるかを話しました。

ケンジ・ウイリアムズさんの最後のスピーチは特別なものでした。スピーカーとオーディエンスという形で再会でき、彼のバイオリンを8年振りに聞く事ができたのです。演じた「Bella Gaia」の一部は音楽と地球規模のデータの融合し、見ている人の意識に作用する素晴らしいパーフォマンスでした。アフターパーティーではBella Gaiaの方と意見交換する事もできました。

熱狂の一日

イタリア人画家のマッテーオさんと会って色々な話を出来た事も大きな刺激でした。絵画が好きなのですが、職業画家の方と話しができたのは初めてです。彼はTEDxTokyo 2005のスピーカーでもあり、話題にした美術や芸術の話は興味深い事ばかりでした。

可能な限り人に話しかけ各分野の興味深い話を聞きたいと思うのですが、プレゼンテーションは沢山ありこれ以上濃くする事ができないくらい濃密な時間はあっという間に過ぎて行きます。

二年目の参加で少しは落ち着いていられるかと思ったのですが、さらにエキサイトして頭に心に全身に作用した熱狂の一日となりました。主催のパトリックさん、トッドさん、ボランティア、チームの方々、スピーカーの方々、そしてパートナーの方々、この素晴らしい一日をつくりあげた方々に感謝します!

TEDxTokyo 2014 Photo Studio
https://www.facebook.com/media/set/?set=a.10152494229284859.1073741838.98089389858&type=3


田子さんありがとうございました! / ボランティアの方達は本当に素晴らしいです。/ Touchyにも会えました。

Action-Domain-Responder

| Comments


https://github.com/pmjones/mvc-refinement

Here is my random thought about ADR.

It seems the each component seems to have their own each distinct and meaningful role. Devs will follow a more natural workflow with it. Domains become first class citizens compared to a “data provider” to their GOD controller in some MVC framework.

I like the fact that an action returns a responder (not actually invoking the action). Data can then be retrieved and tested. Actions can call other actions creating a hierarchical information structure for which MVC stuggles to provide a solution. Testing and gaining 100% code coverage also seems much easier without using a web driver.

I don’t see any particular problem in having “More classes in the application”. I think it can gain more benefit by having a smaller amount of LOC per class. It seems people can move from MVC to ADR with ease and gain the benefits instantly.

I would like to add a few personal slightly biased comments, (Just casual remarks – feel free to dismiss.)

In most MVC application frameworks, the existing system (architecture) is mapped to the web. CRUD and OOP paradigms are mapped to HTTP methods and resources. But the opposite is not true. ADR seems to have the same limitation. I would like to echo @nateabele’s tweet “resources aren’t like controllers, in that they’re intended to be more cohesive”.

I also wonder if I can inject arguments, not “retain incoming data” to an Action, actions can then be an easier to utilize by another Action?

A few questions about the Responder ? “the Action would grab a Domain and represent it through a Responder.” Instead of an Action interacting with the Responder, how about have the Responder look at the Action’s data and use that ? In doing this Action is completely ignorant of the Responder? Or am I misunderstanding something ?

Conclusion:

To discover the next generation web application framework, grasping a new application architecture seems to be crucial, rather than just a gradual improvement of the MVC pattern. I think it is exciting that an influential person like Paul M. Jones (my PHP hero) is pushing these boundaries somewhat. ADR can be a good replacement of MVC pattern, especially for those who have used an MVC framework but also looks forward a little what might be next. I like it.

English proofreading: Richard McIntyre

(Arigato as always :)

PHPNW 2013(2) - Presentation

| Comments

PHPNW 2013(1) からの続きです

“何のためにイギリスまで行って話をするのか”-この問いに対して高い目標を持っていました。

「世界レベルのプロのエンジニア/アーキテクトの人達をインスパイアさせたい」

単に自分のソフトウェアの紹介や、便利な使い方を紹介するだけで終わるつもりはありませんでした。 持ち時間は50分。終わりにQ&Aを考えると40分前後が実質のプレゼンテーションの時間です。自己紹介、DIは自分で、AOPをリチャードさん、そしてRESTを通訳、最後にまとめを自分がするというハイブリッドなプレゼンテーションにしました。

無名のフレームワークの話をどれだけの人が聞きに来るか、想像も付きませんでしたが立ち見は出ないまでもほぼ満席です。知った顔も見えます。(leedsphpでのセッションの人達がまた聞きに来てくれてました。) 多くのボランティアスタッフがphpnwカンファレンスの運営を支えてますが、撮影スタッフはプロです。会場の一番奥にいる2人組の撮影クルーのとなりの壁掛けデジタル時計が15:00:00を指したらプレゼンテーションスタートです。

撮影されたビデオはいまだに公開されていないので、発表ノートと共に全てのスライド77枚を紹介します。

Introduction

(after self introduction)

I was really surprised when BEAR.Sunday was chosen for this great conference session.

I am very happy be here as a speaker.

But, some of you guys may wonder (or may have doubts) about an unknown person talking about an unknown framework. 
But I’m not here to teach you how to use my framework. No. 
I’m here to share a new way of thinking, a new way of solving web problems.

How do we look at these problems. Yes, It’s about outlook.

Ok let’s start.


BEAR.Sunday offers no libraries of its own.

PHP namespaces, PSR, a new coding github culture, unit testing, a new trend of library oriented frameworks… these have all happened recently and push us to a more library oriented way of thinking.

So BEAR.Sunday chooses not to have it’s own components, It uses others from aura, symfony and zend etc.


No libraries, instead, BEAR.Sunday offers three object frameworks.


What is the framework, by the way ?


My friend told me like that.


Dependency Injection framework, Aspect Oriented Framework, and Hypermedia framework for object as a service. … these technology are centered but also widely used in BEAR.Sunday framework.

Let’s take a look one by one.

So which one attracts you ? let’s start DI.

DI Framework

DI … in many case, People said DI is good tool for testing. Well, it is true…but Is it really core value for DI pattern ?
 We will see some another benefit, mainly these two.



DIP, Dependency Inversion Principle.

“How many of you know this principle ?”

(around 70%)


Robert C. Martin says the following.

So I decided that we should take this seriously.


Let’s take look at the code.

BEAR.Sunday uses Ray.Di which is a subset of Google Guice for PHP.

It uses a binding DSL in PHP.


This class needs renderer as a dependency, We annotate it with an injection point.
 You can also annotate setter methods with @Inject.


You then bind the interface to an instance provider. Concrete class, factory or an instance.

This is binding an abstraction to a concretion.


Now the module knows about all of the bindings.

With this module, You can create an injector.


Then, We can pull an instance with bound dependencies using an interface. We do this with the injector that knows all bindings in the application.


You can change an object graph depending on context.

Its not uncommon to see the code like the above. The state is passed in the application logic. 
Then the behavior of the application is changed by the state. Even though we use objects, this is more like procedural programing.

Also concrete class names have been used. to have instantiate objects that are needed.

For better flexibility and simplicity. The code can be changed like below.
This code does not need to changed even if we use another renderer.

We should code a structure, not as a procedure.


In BEAR.Sunday there is a clear distinction between compilation and runtime.

Concrete class names should only appear at compile time.


Then at runtime it looks like this.

Never use concrete class names. Instead use an “Abstraction” or “Plug Consent” that I mentioned earlier. Which is an interface or an abstract class.

When type hinting a concrete class name should never be used.

This is not just for the sake of assertion or error checking, it is here to describe the applications design.


Best practice says you should have only one root object in your bootstrap.

This seems very different what we see in other PHP DI containers ?


It might sound crazy, but we follow this practice.


The role of application object in BEAR.Sunday is very simple. It holds the services that we use in the application script. That’s all.

This application class has no functionality or behavior. Also you will notice that the application holds no mode or any context. There is no global state like for example a globally defined DEBUG or ENVIRONMENT constant.

The context is used how to bind dependencies, not a how to behave in runtime as we saw. That kind of state information has permanently disappeared after injection.
We don’t need it.

The dependencies have already been injected.


Let’s take a look at a BEAR.Sunday application object graph.

You can access it via the development tools.


The AppModule knows all of bindings and their abstractions. The injection is then made to get the root object using these binding rules. The injector now can grab the application object.

Lets see how dependencies are resolved.


A Router, web response, resource client and dependency injector.

These are all the dependencies that are needed by the application object.

In the application script, we can configure the application with these services.


The Application script is a simple script which shows its own structure.

Don’t be surprised for goto statement or global variable. This is pre-”separation of concerns” 
It is a meeting point between the http web world and with PHP object oriented world.

This script tells whole top level application sequence

Feel free to edit it as you like. 

Ok let’s get back to application graph building…



The services in the application script may also need dependencies recursively.



Finally we can get one single object graph. Which is huge.
Even my 27 monitor can’t show all the objects at once.

That is why I made this graph visualizer.



This also another principle of BEAR.Sunday.

It has a unique Runtime DRY*. Don’t repeat the same procedure again and again.

the whole application object graph can be serialized and stored in memory. It is not recreated on each request. All dependency are injected and initialized. *

Super fast.

By this I mean that the whole application object graph can be serialized and stored in memory. It is not recreated on each request.

We can serialize whole application which all dependency are injected and initialized. 
This means a huge boost in performance. Super fast.


Have you got it ?

BEAR.Sunday’s application object is build in the correct way, with DI best practices and performance. 
DI is not only a convenient tool for testability*. That is just one part of the power of DI.

By following DIP completely it can lead us to proper application architecture. 
DI is not a magic wand which automatically upgrades our code.

But if you want to follow OOP principles and write clean code with ease, Its definitely worth it.

Runtime code can be simpler, faster, more flexibility and easy to read.

That is the 1st framework. let’s go to the 2nd !

AOP Framework


Who of you know about AOP?

Have used it?

This is a definition….


  • Have you seen code like in RED? Mixture of business & app logic?

  • It runs fine but….

  • Not good separation of concerns

  • Problems with testing, readability and refactoring.

  • Notice how clean this could be in green…


The Aspect Orientated Framework that BEAR.Sunday uses, implements AOP using what is called method interception.

Let’s look at a simple example.


  • Consumer and method stay exactly the same

  • We don’t need to change them

  • There is no base class

  • There is no special way of writing these classes or calling them

The magic I will show you later.

Upon execution the interceptor does not need to be registered. The interception is registered upon binding.


  • Lets Break up the concerns

  • Pull out the logging etc – this is not business logic, they are app logic

An aspect

  • cross-cuts a method
  • is readable
  • testable
  • completely re-usable and can be re-applied.

Imagine a Rock Concert

  • Band – single concern – business logic
  • Security barrier and guards are an aspect

This is how we use the interceptor in BEAR.Sunday. The interceptor is simple.

  • We invoke the source method as defined
  • Then we retrieve the source object
  • And arguments as needed.

Here is an example of how to use a transaction in AOP.

As you can see the invocation object has been injected using DI.

We can then act upon that wrapping it in a transaction, which rolls back when needed.

Note the $invocation->proceed() method.


A Simple cache interceptor.

  • You can add fancy rules too – this is simple
  • Is the cache there – yes? Just return it, no? Use invocation->proceed

Get the result and warm cache


Create bindings with annotations

  • This shows @db annotation binding
  • @api annotation – JSON would be this implementation.

  • Is MVC enough?
  • Sometimes stuck where to put things?

Much WEB FRAMEWORK functionality is CROSS CUTTING concerns.


An API will often need to change its processing order.


For example:

  • Need AUTHENTICATION when being accessed REMOTELY
  • NOT through the LOCAL app.

  • Some API’s might need Validation or LOGGING.

  • IMAGINE boss asks you to log each DELETE? EASY?


In BEAR these cross-cutting concerns can be registered using

ANNOTATIONS, URI method names.

CROSS-CUTTING CONCERNS attached + detached DEPENDING on context.


  • Model interacted with differently depending on CONTEXT

  • Example FORMS

  • BEAR Sunday Forms are an ASPECTS

  • Can decouple validation


This is the magic

  • It is ugly
  • It is created for you
  • NOT weaver model, AOP Compiler model
  • For Type Safety – For Dependency Injection – Super fast!

INJECTION BY ASPECT

  • MASTER/SLAVE DB
  • master on WRITE
  • slave on READ

The CORE CONCERN is it uses a DB.

The CROSS CUTTING concern is the LOGIC that decides what DB.

  • Extremely testable.
  • Because CORE CONCERN LOGIC does not change.

To wrap UP

The AOP spec in BEAR.Sunday follows the AOP ALLIANCE standard which is common in the JAVA world.

LAYERING of aspects can be freely adjusted DEPENDING on the CONTEXT and environment.

It is TYPE SAFE meaning full dependency injection and seem-less integration with the BEAR compiling step. This is by no means slow!

At runtime necessary components can injected based on look up methods and arguments.

Hypermedia Framework


HyperMedia Framework 、それはオブジェクトをWebサービスのように扱うという試みです。


これがリソースオブジェクトです。URIがクラスにマップされます。

publicプロパティとリクエストインターフェイスがあり、リクエストはステートレスに行われます


リクエストには専用のクライアントが必要です。リクエストを受け取ったリソースは自分の値を決定します。

リソースはまた、他のリソースを必要とするかもしれません。

値がビューコンポーネントに渡され、レンダリングが行われるのではなく

ビューはそれぞれのリソースにインジェクトされ、__toStringメソッドとコンテキストによって出力されます。


HATEOASという言葉を聞いた事あるでしょうか。

アプリケーションのステートをハイパーメディアでドライブします。


@LinkアノテーションとURIテンプレートを使って、リソースをリンクします。


ハイパーメディアAPIはAPIとAPIを繋げ、本当の意味のRESTにします。

Webのように、リソース間の関係をクライアントではなくサービスが持つのです。


world wide webが成功した理由。

それをアプリケーションアーキテクチャの中心にします。


REST、つまりAPI開発を開発の中心にしているです。

かつてはDBはエンタープライズのコアバリューでした。FWや言語が変わってもDBがあれば良かったのです。

今APIがコアバリューです。

APIはハブです。複数のクライアントとストレージ、あるいは他のサービスと接続します。


アンクルBobのClean Architecture、この図を見た事あるでしょう。

(around 50%)


BEAR.Sundayのリソースは同じようにレイヤリングされています。RESTのネイチャーです。

アプリケーションスクリプトがページリソースにリクエストし、ページリソースはアプリケーションリソースをリクエストします。

webページの後ろに何が有るのが露出(expose)していないように、背後のリソースが隠れるのです。


実際のリソースをみてみましょう。

緑のラインがページリソース、それは赤いラインのアプリケーションリソースで構成されています。


開発画面ではURIとそのバウンダリー、そして開発ツールが表示されています。

リソースのロジックとビューはオンラインで編集可能です。


ページリソースはwebページの役割をし、HTTPのメソッドに対応したリクエストメソッドを持ちます。

パラメーターを見て下さい。フォームとPHPのメソッドは統合され同じパラメーターをもっています。 

手続きではなくて契約を表しているのです。


リソース中心、のBEAR.Sundayではこのような一覧表示は自然なことです。
 メソッドをクリックしたらフォームが表示されそれぞれのテストができるようになる…のは少しお待ちください。


アノテーションやDI、これらの言葉はパフォーマンスLoverにとって悪夢に聞こえないでしょうか?

実際は構成済み(configured by context)のオブジェクトが再利用されるので、これらのコストは0になるのです。

フレームワークとしての最大限の柔軟性を持ちながら、パフォーマンスは非常に良好です。


リソースの指定にはクラス名ではなくてURIを使います。

Facebookが開発したThriftを使えば、高速なJavaプログラムを同じURIでコールする事ができます。


プログラムは変わりやすいところと変わりにくいところがあります。 我々はそれぞれハードスポット、ソフトスポットと呼んでいます。

システム毎に決まる変更点はハードスポット、一旦構成されればリクエストの度には変わりません。 例えばDBのIDや利用するテンプレートエンジンの種類です。

アスペクトはソフトスポットを取り扱います。例えばメソッドによって接続DBを変えます。

What is BEAR.Sunday ?

BEAR.Sundayは接続フレームワークです。 
DIはオブジェクトとオブジェクトを依存性によって接続します。アプリケーションはオブジェクトグラフとして表されます。

同じインターフェイスしかし違う実装でオブジェクトを繋ぐ事で、HTML表現の普通のアプリなのか、それともモバイルアプリケーションのためのAPIアプリケーションなのかを決定するのです。

AOPはドメインロジックとアプリケーションロジックをつなぎます。メソッドインターセプションは驚くべき簡単な仕組みで、本質的関心と横断的関心を繋ぎます。

AOPプログラミングに行ったん慣れてしまうと、一体以前はどこにログやトランザクション、認証やバリデーションを置く事ができたのか不思議に思うでしょう。

REST – Hypermediaは情報と情報、リソースとリソースを接続します。リソースは意味によって繋がれ、そのリンクはサービスサイドで変更可能です。

情報に真の意味での価値を与えるのはその繋がりです。APIをハブに、RESTを中心にしたロングタームのアーキテクチャをするのです。


BEAR.SUndayはアブストラクションフレームワークです。

抽象化のためのテクノロジーを最大限使用しています。

実装を直接表すのではなく、抽象化された意図(intention)を表します。

アノテーションでアプリケーションロジックを、ハイパーリンクでリソースとリソースの関係を表すのです。手続きではなく、関係性を記述するのです。

コンテキストと束縛によって、その意図に実装(implementation)が与えられます。

@Transactionalとアノテートしたメソッドにはトランザクションコードがラップされ、URIには全く別の言語の別のメソッドをマップする事が原理的に可能なのです。


We had a lot of technical talks.

3 frameworks in one session ? You must be tired.

Lets take a break with this beautiful English garden.

It is full of flowers, trees, fountains. It seems to offer everything. 
Each garden has its own style but fundamentally has a similar design.

They certainly seem joyful and certainly contain many great features and are welcoming.

Visitors can enjoy the garden as the gardener intended them to. 

For me, many frameworks look like this English garden.

Now, Look at a Zen garden.

No water, No trees or flowers.

There is nothing here that’s common in western gardens.

But you will notice after some time, it offers nothing but perfect harmony.

This garden has only abstraction. Your imagination and your mind can reflect on this garden (when it’s ready.)

Minimalism. Look at this garden, what can I remove? Nothing, it’s impossible!
 The opposite way of thinking is more common. You add more elements and functions until you can’t add anymore, then you will think. “oh now it is complete.” 
When I built this framework, I thought:  ‘How can I reduce the rules or code base? without loosing any functionality by design’

To provide the best tools, I decided not to try and develop them myself. It’s impossible. A lot smarter people can make better tools.

Instead, I decided to provide the maximum freedom you can then choose the best tools with proper constraints.

Freedom doesn’t meant, You can chose anything for any part. You can’t wear jeans under a kimono. 

You need harmony, you need good constraints.

BEAR.Sunday wants to be your zen garden, zen framework.

I hope your imagination, your creativity can be maximized through this connecting framework, a harmony framework.

Lastly, don’t put ’d’ after ‘n’, That’s another framework. Thank you very much.


Do-mo, Arigato.

力を尽くし臨んだプレゼンテーションは、次の人が「ちょっとやりにくい」と言ってくれたぐらい大きな拍手で終了しました。

(続く)

PHPNW 2013 (1)

| Comments

2014年、あけましておめでとうございます。 年が変わってしまいましたが、2013年のBEAR.Sundayにとって最大のイベントphpnw13に参加した事を記事にします。

20 June; CFP (Call for Paper)

phpnw(PHP North West)カンファレンスはイギリスのマンチェスターで2008年から毎年開催されている欧州でも有数の規模のPHPカンファレンスです。 スピーカーとして参加する為にはCFPが必要で、単に「自分の興味ある技術的な話をします」ではなく“why we should accept your talk” (なぜ主催者達が自分の応募を採用するのか)という事を伝えなければなりません。 以下のようにタイトルを3つ考えました。

  • API driven development for API driven World
  • Think differently, REST centric approach solve REST problem effectively.
  • A resource orientated framework using the DI /AOP/REST Triangle

採用されたのは3つ目です。そのタイトルに沿った詳細な紹介文を通訳兼共同発表者のリチャード(@mackstar)さんに用意してもらって応募しました。

Many web developers have a REST or API part of their app when offering it as a service. In this session I will show you how in making REST a central part of your design you can have a huge amount of consistency at the core of how you code. REST gives us much of the power we need in development and is not just for API’s. This session will completely change the way you think about REST. BEAR.Sunday is a REST-centric framework that makes you think totally different about how to go about architecting web-apps and platforms to the maximum potential with elegance.

03 July; 採用

採用の返事が来たのは7月4日。夏期休暇でスイスを友人とレンタカーでドライブをしてた時に連絡がありました。

We were delighted to hear from you and we would love to extend an invitation for you to give your talk “A resource orientated framework using the DI /AOP/REST Triangle” at our conference.

採用された事に驚きました。そして今スイスにいるのにまた三ヶ月後にイギリスに返るのかとも思いましたが、友人は「行くしか無い、他の選択肢はない」とはっきり言い切ります。 英語のプレゼンも、舞台の大きさも、完全に自分のキャパシティを超えてましたが腹を決め渡英するとの連絡をしました。

採用のプロセスは厳しくキュレーターが4人全ての人の採点が10点中の9か10が必要です。200以上の応募があり採用率は15%以下。 技術レベルは三段階の最上位での応募でした。「基本的にみんなフレームワーク選択の話にあまり興味はない」との事で応募はかなり無謀だったのですが、一緒に発表をするリチャードさんのクレジットもあり採用されました。 3つのトラックが同時進行して、ホールは大中小の大きさがあります。選ばれたのは定員100人程度の真ん中の大きさのホールでした。

28 Sep; @leedsphp ユーザーグループとBBC

どうせ渡英して話すならと地元のleedsphpユーザーグループのmeetupとリチャードさんが働くBBCでもセッションを持つ事になりました。いわば大舞台のphpnwのカンファレンスの練習です。 日本の勉強会のようなものですが、流石イギリスというか、雰囲気のある場所です。

手元の書類が見えにくいぐらい照明を落としたところで最初のスピーチをしました。 機材トラブルもあり、スピーチそのものできはあまり良くなかったのですがかなりの熱を持って聞いてもらう事ができました。

通常は(日本と違って)トークが終わると基本すぐに解散らしいのですが、終わった後もみなさんといつまでも色々な事を話ました。「こういう反応は今まで見た事がない」反応だったそうです。 興味を持って質問を積極的にしてくれた方はSymfonyを使っている人が多くSensio Labsの方もいました。元々Symfonyユーザーは多いのでしょうが、日本のSymfonyユーザー会の人達の縁ある事もありなにか不思議な感じです。

次はBBCです。ここでのセッションが一番緊張しました。

BBCでの経験は驚きの連続です。世界最高のメディア企業でのWebプロダクト制作、その現場です。 とにかくかっこよくて、詳しい事が書けないのは残念です。一日始業から終わりまでインターンのように過ごす機会にも恵まれその現場の空気やワークフローの実際に立ち会う事ができました。 シニアアーキテクトのマシューさんとのランチの機会も頂きました。「軽いおしゃべり」という予定だったのですが、ほとんどの時間はBEAR.Sundayについての質問とその答えというやり取りになりました。 質問が非常にシャープで的確です。「そのアーキテクチャのポイントを、ノンテクニカルな人に3分で伝えるとしたらどう話す?」等、こちらが試されるような質問の連続です。 真剣な質問に真剣に答えます。手応えのあるやりとりは満足のできるものでした。

とても緊張してプレゼンテーションを行いました。イギリスのバーの二階でやったleedsphpユーザーグループの時と違って、就業中に時間をさいて集まってくれたBBCのWebエンジニアの方々はとても真剣です。 しかし内容を高く評価してもらいphpnwでの発表が少し安心できるものになりました。またアーキテクチャにとても関心が高い事の確信も得られました。 (BBC Future Media SportsのSenior Technical Architectのマシュー・クラークさんとリチャードさんの三人とBCの食堂でランチ。)

phpnw13

02 Oct; Hackason

カンファレンスの前日金曜は昼間はチュートリアル、夜はハッカソンがあります。ハッカソンと言っても日本のものと違って何かを個人で制作して発表するとかではありません。 例えば「PHP-Excel」とか並んでいるテーブルにプレートがあるので、自分の協力したいオープンソースのテーブルに加わりコーディングしたりおしゃべりをしたりするのです。終わる時に特に発表もありません。 カンファレンスの前日のソーシャルな時間とも思えました。@leedsphpで知り合った人達にも会え、色々話す事ができました。

05 Oct; 発表の日

セッションは土曜日から始まります。オープニングキーノートはLorna MitchellさんとIvo Janschさんの 0x0F Ways to be a Better Developer (より良いディベロッパーになる0x0Fの方法)。

会場は2つに別れていて、二人のスピーカーを映像で繋げそれぞれ交互に変わりながらプレゼンテーションを行うといった凝った仕掛けです。キーノートのテーマがPHPの進化や特定技術ではなくて「より良い開発者になる」というのは印象的でした。 例えば“Get Out of Your Comfort Zone” 「普段の安全で良く知った自分のフィールドから飛び出し、リスクをとって”Enjoy the unknown”しましょう」という事ですが、 「今回マンチェスターで自作のフレームワークのプレゼンテーションを行うのは充分Get Outしてますしてます。the unknownを楽しんでます!」と頷きながら聞いてました。

自分達の発表の練習や最後の準備もしなければなりませんが、聞きたいセッションも沢山あります。プレンゼンテーションの内容は非常に充実していて、スピーカーも普段もネットで目にするような有名な人ばかりです。

phpnw13 Schedule http://conference.phpnw.org.uk/phpnw13/schedule/

「speaker shadowです」1人のスタッフが現れました。どうもスピーカーの世話をする人の事をspeaker shadowというようです。かっこいい言い方するんだなあとか思いながら、装備するワイヤレスマイクや接続するMacの手順などの打ち合わせをします。

スピーカーに対するケアがとても手厚いのです。phpnwは有料カンファレンスで、チケットは£135.00(現在12/31のレートで23,430円)します。 スピーカーに報酬はありませんが、滞在中の食事や宿泊費は全て賄われます。ホテルの部屋にはエッセンシャルキットと言って、ミネラルウォーターや洗面道具のキットのwelcomeセットのようなものが部屋に用意されています。 スピーカーだけにトレーナーやギフトもありました。食事は例えば、スピーカーディナーはコース料理なのですがそのメニューは事前にwebで注文しておく事ができ、例えばベジタリアンの人などへの配慮もあります。 スピーカー同士の交流が図られるという事が大事です。食事の度に顔を合わせて一緒に話したりするので自然と交流が持て色々な話が聞けます。

いよいよ、時間が近づいてきました。 前のセッションはDrupal。世界のPHP開発者の誰もが知るプロダクトでスピーカーはその開発者、立ち見がでるくらい満員です。

その次が自分達の番、誰も知らないフレームワークの発表です。

(続く)

BEAR.Sunday England Tour 2013

| Comments


無名の個人が作った無名のフレームワークをこれだけの規模のカンファレンスで発表するというのを聞いた事がありません。そもそも「誰も新しいフレームワークに興味が無い」というこで、新しいどころか世界の誰もが知っているフレームワークが200を超えるCfPの中で落選してる事も知りました。

そこでこういう言葉でセッションを始めることにしました。紹介します。

It’s an honor to be here as a speaker.
But, some of you guys may wonder (or may have doubts) about an unknown person talking about an unknown framework.

But I’m not here to teach you how to use my framework. No .

I’m here to share this new way of thinking, a new way of solving the web problem.
How do we look at the problem.

Yes, It’s about outlook.

Ok let’s start.

こういう機会を得られたのはリチャードさんという素晴らしい開発者のこれまでのコミュニティに対するコントリビュートがあり、彼のアクションに周りの信認があるからだと思ってます。そのリチャードさんにphpmatsuriというイベントで出会う事ができ交流を持てた事も縁です。

機会や縁に感謝しつつ、挑戦の旅に出かけます。

PEAR

| Comments

What is PEAR ?

公式サイトのトップページに、PEARとはなにかがこのように説明されています。

What is PEAR ?

PEAR is a framework and distribution system for reusable PHP components.

PEARはフレームワークであり、再利用可能なPHPコンポーネントのディストリビューションシステムです。

PEARの持つ2つの側面。フレームワークディストリビューションシステムと簡潔に説明されています。

PEARの誤解

PEARは一般にいくつか誤解されてるようです。

グローバル

PEARはグローバル専用でなく、「ひとつのプロジェクトにおける依存関係を管理」に利用することは可能です。特殊なHackなどではなく、標準で用意された方法です。

.pearrcをconfig-createで作って、オプションで指定するだけです。

1
2
3
$ pear config-create /path/to/pear .pearrc
$ pear -c /path/to/pear/.pearrc install PEAR
$ pear -c /path/to/pear/.pearrc install PEAR Cache_Lite

BEAR.Saturdayでもユーザー環境へのインストールを紹介していて、実際多くのプロジェクトがプロジェクト単位で構築されて駆動しています。

チャンネル

作成したパッケージをwebでサービスするために、パッケージ登録のための投票を受ける必要はありません。それは公式のチャネル pear.php.netでの話です。公式に載せていない、独自のチェンネルでサービスをしているパッケージも沢山あります。BEAR.Satuday http://pear.bear-project.net/ もその一つです。

どちらも改善の余地はあるものだったのでしょうが、機能的には可能でした。またPEARの大きな特徴として後方互換性の完全な維持がありました。

BCブレイク

PEARは後方互換性を破らないという厳しいルールがありました。BEAR.Saturdayは沢山の依存PEARパッケージがあり、数えきれないほどPEAR upgradeしましたが問題が出た記憶がほとんどありません。 バージョンが.1あがったら互換性でエラーだらけになるような事は決してありませんでした。

依存管理で正確なバージョンを特定しなくても、最新バージョンを入れれば機能しました。しかしこれは、そこまで厳格でないパッケージの依存を扱う時に困った事になります。composer.lockのような機構はありませんでした。PEARのような高い品質を持ったライブラリ同士でなければ問題になってしまいます。

PEARはフレームワーク

PEARはコード作成に関する標準スタイルや共通のエラーメカニズム、バージョニング、ディストリビューションをも含んだ包括的なフレームワークです。Internet ArchiveによるとPEARに初出は2001年です。こんなに速い時期からこんなフレームワークが提供できたのはPHPコミュニティの誇れる歴史です。

後に続く非PEARのアプリケーションフレームワークやライブラリは、この偉大な先輩にリスペクトを持ったものと、全く持たないものがありました。コーディング規約やフォルダ構造を見れば分かります。1 例えばPEARのフォルダ構造はPseudo-namespace(PHP5.3以前のなんちゃって名前空間)に従ったもので一貫性がありauto loaderが簡単に実装できましたが、独自のフォルダ構造をもちクラスファイルの読み込みに大変なコストがかかるものもありました。2

ただ、その高すぎる理想と、GitHubを中心とした新しいコーディング文化、PHP5.3以降のライブラリ群の依存要求、Pyrus移行の失敗、など様々な要因によってPHPの依存管理の主役の座をComposerに明け渡す事になります。

しかしPEARは当時のPHPの最良を提供しようとした、意欲的で完成度の高い包括的なエコシステムです。今のPSRやコーディングにも多くの影響を与えています。単に古く間違ったプラクティスとして忘れてしまおうという考えには賛同できません。主役の座は受け渡しましたが、今でもいくつものライブラリは有用だしディストリビューションシステムとしても健全で機能します。公式サイトでホストされてるライブラリは複数のレビュアーが承認した質の高いコードで、コードリーディングのテキストとしても有用です。

PEARはPHPコミュニティの誇れるべき財産だと考えます。

  1. BEARは前者です []
  2. 何のための逸脱なのか分かりません []

Ray.Tutorial – First DI Framework

| Comments

初めてのDIフレームワーク

準備

  1. PHP5.4+で動作します。mysqlで予めテーブルを作成しておきます。 2 フォルダをつくります。
1
2
$ mkdir ray.tutorial
$ cd ray.tutorial

まずは手動でインジェクションするコードソースを入力して実行します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<?php
class Todo
{
    /**
     * @var PDO
     */
    private $pdo;

    /**
     * @param PDO $pdo
     */
    public function __construct(PDO $pdo)
    {
        $this->pdo = $pdo;
    }

    /**
     * @param string $todo things to do
     */
    public function add($todo)
    {
        $stmt = $this->pdo->prepare('INSERT INTO TODO (todo) VALUES (:todo)');
        $stmt->bindParam(':todo', $todo);
        $stmt->execute();
    }
}
$pdo = new PDO('mysql:dbname=test;host=localhost');
$todo = new Todo($pdo);
$todo->add('Get laundry');

実行してみます。

1
$ php manual-di.php

データベースにtodoが入力されたか、コンソールかツール等で確認します。1 確認できましたか?OK? では、次にcomposerのプロジェクトを作ってこのクラスをDI化してみましょう。

composerでRay.Di依存の空プロジェクトを作る

まずはcomposerをダウンロードします。

1
$ curl -sS https://getcomposer.org/installer | php

composerを使ってRay.Diを使うプロジェクトを作ります。

1
$ php composer.phar init

すると色々質問されるので、ray/diのバージョン* (最新の安定板)をインストールするように答えます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
  Welcome to the Composer config generator
This command will guide you through creating your composer.json config.
Package name (<vendor>/<name>) [akihito/ray.tutorial]:
Description []:
Author [Akihito Koriyama <akihito .koriyama@gmail.com>]:
Minimum Stability []:
License []:
Define your dependencies.
Would you like to define your dependencies (require) interactively [yes]?
Search for a package []: ray/di
Found 15 packages matching ray/di
   [0] ray/di
   [1] ray/aop
   [2] jms/di-extra-bundle
   [3] aura/di
   [4] orno/di
   [5] league/di
   [6] mnapoli/php-di
   [7] zendframework/zend-di
   [8] mnapoli/php-di-zf1
   [9] ocramius/ocra-di-compiler
  [10] lcobucci/di-builder
  [11] aimfeld/di-wrapper
  [12] kdyby/autowired
  [13] seiffert/console-extra-bundle
  [14] vojtech-dobes/extensions-list
Enter package # to add, or the complete package name if it is not listed []: 0
Enter the version constraint to require []: *
Search for a package []:
Would you like to define your dev dependencies (require-dev) interactively [yes]?
Search for a package []:
{
    "name": "akihito/ray.tutorial",
    "require": {
        "ray/di": "*"
    },
    "authors": [
        {
            "name": "Akihito Koriyama",
            "email": "akihito.koriyama@gmail.com"
        }
    ]
}
Do you confirm generation [yes]?
</akihito></name></vendor>

入力の必要な質問はこれだけでした。

1
2
3
Search for a package []: ray/di
Enter package # to add, or the complete package name if it is not listed []: 0
Enter the version constraint to require []: *

すると最後に表示されたcomposer.jsonが出来上がりますが、まだray/diはインストールされていません。installコマンドでインストールします。

1
$ php composer.phar install

initコマンドで作成したcomposer.jsonに従ってRay.Diとその依存ファイルとダウンロードされ、現在の依存の状態が記録されたcomposer.lockファイル、それにautoloaderを含むcomposerのファイル群もインストールされました。

1
2
3
4
5
6
7
8
9
10
$ tree -L 2
├── composer.json
├── composer.lock
├── composer.phar
└── vendor
    ├── aura
    ├── autoload.php
    ├── composer
    ├── doctrine
    └── ray

Ray.Diを使ったコードを入力してsrc/フォルダを作ってその下に配置します。 src/todo3-ray-di.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<?php
use Doctrine\Common\Annotations\AnnotationRegistry;
use Ray\Di\AbstractModule;
use Ray\Di\Injector;
use Ray\Di\Di\Inject;
use Ray\Di\Di\Named;
$loader = require dirname(__DIR__) . '/vendor/autoload.php';
AnnotationRegistry::registerLoader([$loader, 'loadClass']);
class Todo
{
    private $pdo;
    /**
     * @Inject
     */

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

    /**
     * @param $todo
     */
    public function add($todo)
    {
        $stmt = $this->pdo->prepare('INSERT INTO TODO (todo) VALUES (:todo)');
        $stmt->bindParam(':todo', $todo);
        $stmt->execute();
    }
}
class Module extends AbstractModule
{
    public function configure()
    {
        $pdo = new PDO('mysql:dbname=test;host=localhost');
        $this->bind('PDO')->toInstance($pdo);
    }
}
$injector = Injector::create([new Module]);
$todo = $injector->getInstance('Todo');
/** @var $todo Todo */
$todo->add('Walking in Ray');

これがRay.Diを使ってDIを行っているコードです。変わった部分をそれぞれ見て行きます。

オートローダー

1
2
$loader = require dirname(__DIR__) . '/vendor/autoload.php';
AnnotationRegistry::registerLoader([$loader, 'loadClass']);

composerを使うと依存ファイルのオートローディングの設定が含まれた、vendor/autoload.phpというオートローダーのファイルが自動で生成されます。 Ray.DiのアノテーションはDoctrineのアノテーションを使っています。アノテーションの読み込みにはオートローダーの登録が必要で、いくつかの方法がありますがここではcomposerのオートローダーをそのまま使っています。

アノテーション

1
2
3
4
5
    /**
     * @Inject
     */
    public function __construct(PDO $pdo)
    {

依存を受け取るメソッドには@Injectとアノテート(注釈)されています。Ray.Diはこのアノテーションを目印にして依存が必要なメソッドを割り出します。2 アノテーションはクラスで、名前解決のためuse文が必要です。3

1
use Ray\Di\Di\Inject;

モジュール

モジュールでは依存を必要とする場所に依存をどう渡すかを記述します。

1
2
3
4
5
6
7
8
class Module extends AbstractModule
{
    public function configure()
    {
        $pdo = new PDO('mysql:dbname=test;host=localhost');
        $this->bind('PDO')->toInstance($pdo);
    }
}

AbstractModuleを継承したクラスのconfigure()というメソッド内で、bind()メソッドを使って依存を束縛(バインド=結びつけます)します。ここではPDOクラスを必要とするインジェクションポイントに作成した$pdoインスタンスを束縛しています。 これによってアノテーションの節で説明したように@injectとアノテートされPDOクラスのタイプヒントを持つ引き数には$pdoインスタンスが渡されるようになります。

インジェクター

モジュールを使って作成したインジェクターは、どの依存が求められれば何を渡せばいいかを知っています。そのインジェクターを使って’Todo’クラスを取得するとインジェクターは必要とされる依存をモジュールで決めたルールで渡し、依存解決(dependency resolution)が行われます。

1
2
$injector = Injector::create([new Module]);
$todo = $injector->getInstance('Todo');

ついに出来ました!!!! $todoオブジェクト!!! 依存の問題を解決(外部の変数を外側から渡す)を自動化するために、様々な事が必要になりました。 依存が必要な箇所にアノテーションが必要です。そのアノテーションクラスのオートローディング登録も必要で、モジュールでも依存の束縛の記述、束縛を使ったインジェクターの作成をしてようやく依存解決をするインジェクターが作成されました。 1つの問題を解決するためにこれだけの事をしたのです。4DIフレームワークはRayだけではありません。他のDIフレームワークも同じような、あるいはこれ以上の準備の手順の複雑さを持っています。

オーバーエンジニアリング?

オーバーエンジニアリング(作り込みのし過ぎ、過剰技術)でしょうか? まず、他の技術同様に、説明のための単純な例で実利を感じる事は往々にして難しい事は頭に入れておく必要があります。例えば、HelloWorldのサンプルでフレームワークのメリットを実感する事はなかなか難しいでしょう。 DIフレームワークの使用がオーバーエンジアリングか、クラス名のハードコーディングがアンダーエンジニアリングなのか、その辺りの判断を直感で出すのはひとまず置いといて、Ray DIフレームワークの使い方の実例をもう少し見て行きましょう。 …続く

  1. あるいはSELECTをするメソッドを追加してください! []
  2. コンストラクタ以外でも依存を受け取る事ができます。@Injectとアノテートしてメソッド名は何でもかまいません []
  3. Doctrineアノテーションの仕様です []
  4. NateさんのLithiumのスライド A Framework for People who Hate Frameworks – Lithium もご覧下さい []