BEAR Blog

Because everything is a resource.

PHPNW17

| Comments

時間が経ってしまいましたが、2017年の秋にイギリスのリーズとマンチェスターで登壇した事を記事にします。

トラブル発生

行きの飛行のトランジットの時間がギリギリで、乗客は間に合ったのですが荷物の載せ替えが間に合わずスーツケースが未着、翌日宅配便で届くということになってしまいました。

教訓)トランジットの短い便は、絶対に必要なものは手荷物にすべし。その日の着替え、プレゼンの時はPCは手持ちで!

本番前日にスーツケースが届いたのですが開けるとなんとMacBookがありません!。盗難かと一瞬思いましたが「Mac を探す」アプリを起動すると9,294km離れたところで反応があるのが確認できました。つまり日本の家に単に忘れてただけ!😵… iCloudに助けられました。友人の奥さんにMacbook Airを借りて急場をしのぐことにします。

Sky Sports

Sky Sportsというイギリスの衛星放送事業者でPrincipal Software Engineerの職につかれているRichard McIntyre氏の招きで、リーズにあるSky Sportsで登壇する機会をいただきました。 (Sky Sportsは(プレミアリーグの放映権を全て持っているぐらいの)世界でも最大級の放送事業者で、以前講演したBBC Sportsよりも規模の大きい放送事業者です。Skyはツールドフランスでも有名ですよね)

Sky Sports 2017

(Skyのカフェに小さなポスターが貼ってありました)

“Crating rih universal React apps powered by RESTful PHP"と長くてかっこいいタイトルはRichardさんが考えてくれました。 「"Hypermedia APIは自己記述的でヘッドレスアプリケーションとして機能する。それにSSRのReact UIを組み合わせるアーキテクチャ」というのを紹介しました。

以前Sky SportsでReactのSSRを検討した時にはパフォーマンスに問題があって一度断念しているという話を聞いていたのと、ヘッドレスCMSの人気が出て来ているという話を聞いてたので、その解決法と"ヘッドレス"を含んだプレゼンテーションにしました。自由参加だったのですがその部署のほとんどの人に参加していただいたようです。

今回のチャレンジは「英語のスクリプトを用意しない。英語は下手でもいいから読まずに話す」でした。あらかじめ用意する英語よりも文章は下手になりますが、聞いてる方はトークを聞きに来ています。正しい英語を話す自信はありませんでしたが、これは弁論大会ではなくて技術トークなんだと、参加者は私の英語を採点するためではなく技術の話を「聞きに来ている」のだと自分を言い聞かせて臨みました。カフェのアットホームな雰囲気もあって、会議室のBBCの時ほどは緊張せずリラックスして話せてやっぱり読まずに話して良かったと思いました。

このトークをこのSky Digital ContentのSenior Software EngineerのChris Bellさんに記事にしてもらっています。

Akihito Koriyama visits Sky to talk React apps powered by RESTful PHP

終わったあとも質問が長く続き、良いコミニケーションが出来たと思います。

同じトークをphpnwカンファレンスのunconfでしました。

PHPNW

PHPNW(php north west)は2008年に始まり、今回参加した10回目の2017年phpnw17で幕を閉じました。

http://conference.phpnw.org.uk/phpnw17/extras/previous-conferences/

そのうちカンファレンススピーカー枠で参加したphpnw13 、アンカンファレンス参加したphpnw15、phpnw17と3回参加しました。

イベントは通常三日間行われます。最初はカンファレンスの前日にあるTUTORIAL DAYです。

チュートリアルはカンファレンス料金とは別の代金が必要で1日で£250 (約37,000円)、半日で£145です。

チュートリアルの費用を会社に出してもらってる開発者も多く、面白いのはそれをサポートする仕組みがあることです。

カンファレンスやチュートリアルに参加することがどれだけ意義があってそれが費用に見合うものかというbossを説得するPDF資料が用意されています(!)

  1. 素晴らしい従業員を引き留めることができる
  2. あなたの"スーパースター"を育てることができる
  3. 未来への展望

会社がお金を出したくなるような言葉が並びます。 他にも他の地方や外国から訪れている方のために、半日や一日観光などおすすめ観光情報も用意されていました。地元をプロモートしたいのだそうです。

ハッカソン

チュートリアルデーの夜はハッカソンです。 ハッカソンと言ってもチームに分かれて何かを競うわけではなくて、ソーシャル(懇親)が目的です。 「PHP-Excel」とか「Joind.in」とかプロダクト毎にテーブルが分かれていて、好きなテーブルに座りそれぞれのオープンソースのプロジェクトにコントリビュートします。

オープンソースのコントリビュートでカンファレンスを始める、そしてそのコントリビュートをソーシャルにする。素晴らしいと思います。

(phpnw2013のハッカソン)

特にハッカソンに参加せずに他の参加者とおしゃべりするだけでもOKです。写真中央のスクリーン前にいる人たちはゲームで遊んでます。(ハットをかぶってる人はスピーカーのRoss Tuckさん)

カンファレンスセンターにはバーと中庭があってゆっくり過ごせます。

夜になると夜食も出ます。スピーカーの人達は事前にスピーカーディナーで別になっててちょっとしたコース料理を楽しむことができます。。ベジタリアンメニューとかどいう食事をしたいか事前にwebで選択できます。

今回初めて一人、地元の友人なしで行きました。食事の時間の時、BEAR.Sundayを使ってるKennyさんを見つけて一緒のテーブルに混ぜてもらいました。

左の写真はJakeさん、iOSのNextGen UIというUIで有名な開発者です。

Kennyさんは翌日はphpnwで初めてというバンド演奏でドラムを叩いてました。かっこいい! (そのバンドのサイトをBEAR.Sundayで作りたいそうです)

カンファレンスは二日あります。

1日目は開会挨拶(10分)、スポンサー紹介(15分)の後にオープニングキーノート(50分)と続きます。

4つのセッションが3トラックで行われます。ルームサイズはそれぞれ大中小。1つのセッションはどれもQA含めて50分。

  • 50分のキーノート
  • 10分のインターバル
  • セッション(1)
  • ☕️ 25分のブレイク
  • セッション(2)
  • ☕️ 70分のランチ
  • セッション(3)
  • ☕️ 25分のブレイク
  • セッション(4)
  • 50分 Platium Sponsor & Prize
  • 50分のインターバル
  • 19:00 夕食&ソーシャル - 深夜

ブレイクの時間はカンファレンスルームをみんな離れてホールで過ごします。 提供されたコーヒーやお菓子を手に、スポンサーブースを見たり聞いたばかりのセッションの感想を参加者同士で話し合ったりするソーシャルのための時間です。 時間25分と長めで振り返ったりブースも見れたりできるので良かったです。

(phpnw17でのキーノートの映像はまだ公開されていませんが同じ内容の映像がありました)

PHPの歴史と進化の話でした。

スライド http://talks.php.net/vienna17#/

中でも印象的だったのがphp7の移行を呼びかけるところ。

「世界には20億のサイトがあり、1000万台の物理サーバーが存在する。 そのうちの少なくも半分はPHPサーバー、しかしphp7はまだphp全体の5%(約25万台)しか使われてない。 しかしその5%でもサーバー使用料が$200M(210億円)、750MHの電力、375MkgのCO2がphp5に比べて節約できている。 これがもし100%になると.. 使用電力も二酸化炭素排出も減り、世界をより良い場所にすることができる。php7への移行を!」

php7のアップグレードは地球を救うことになります!😅

他にはオペコードの最適化が進んで、未使用のコードや未使用変数のコンパイルを行わないなどダメなコードほど恩恵が受けられることなども説明していました。これは7.1、7.2とバージョンが進むほど効果があるそうです。参加者が「じゃあWordPressはすごく早くなるのか?」と途中で聞いたらラスマスさんは苦笑しながら「いやWordPressのコードはスタイルは古いけどそんなに悪くないんだ」と答え、しかし「プラグインのコード知らないでしょ?」(会場爆笑)というやりとりもありました。

大規模CMSのアプリケーションアーキテクチャの話は印象に残りました。

大規模というのは単に秒間リクエストの話だけはなく問題の複雑さの事で、それに対してどういうアーキテクチャやソフトウエア技術で解決するかというインスピレーションを得られる内容でした。ルーマニアのgeekを自称する方で、母でありアーキテクトであるというすごい方でした。

2回目のunconfはskyでの45分のものを30分にするので少し駆け足になりましたが、良いトークになったと思います。 ブログ記事やjoindinでのレビューもいただきました。

[PHP North West 2017] – Conference Review

I really enjoyed this talk. I wish I had taken further notes around Akihito’s implementation of Server Side Rendering, which has become a problem for me in the time since attending PHPNW17.

joindin review

Short, but concise and inspired talk about aspect-oriented programming. Brilliant insights into building scalable, and future-proof application domain boundaries using BEAR.Sunday to generate HATEOAS compliant API’s; with realtime synthesised documentation.

ちなみに日本のような参加者全員で聞く最後のLTはありません。スポンサーセッションと夕食、ソーシャルの時間に続いて1日目が終わります。

二日目は半日で終わりますが、これは遠方から来てる人たちがその日に帰れる配慮です。 1度だけ30分のBreakがありますが、半日しかないので1日目より速い進行です。

最後に25分のクロージングキーノートがあります。 For The Love Of CodeというPHPコミュニティに関しての話でした。ちょっとハートフルな内容です。

“The talk is centred around the idea of community. PHP has one of the best communities we know. Its people are passionate, enthusiastic, loyal, and smart. But, there is a problem. We somehow feel, whether we like to admit it or not, that for our community, our language, to be great, it must be at the cost of another community or another language. Perhaps a framework we don?t like so much, or another language that thinks is better than ours. We make little remarks, or take cheap shots at the ?competition?. But it doesn’t have to be that way. When I started coding all those years ago I had no idea there would be hoards of other developers waiting to share ideas and pass on the knowledge - all for the love of code. Which is the real reason we?re all here. We all love code. The talk will revolve around the idea that all software-based communities have so much in common. That we all have a common purpose - to share and promote the thing we love. But we can promote our community without detracting from others. Using the philosophy of "Think Win-Win” from The 7 Habits of Highly Effective People, I will discuss how shift in attitude can means we can all promote our beloved language and promote others too, and still win."

そのあとの終了の挨拶で「今年でphpnwの開催を最後にする」との突然の発表がありました。 直後にどよめきがあり、その後に拍手に代わりそして長いスタンディングオベーションになりました。主催者のジェレミーさんも壇上で言葉に詰まっています。

「ああ、それでキーノートがラスマスさんだったんだとか、迷ったけど今年来て良かったとか」とか様々な考えが頭に浮かびます。

10年続いたPHPNWは終わりました。やはり毎年の開催は大変な苦労で、10年を区切りと考えたそうです。 カンファレンス終わった後、一緒にクロージングキーノートを聞いてたJakeさんが彼のCIVICで空港まで送ってくれ、マンチェスターを後にしました。

PHPNW

そもそも私がPHPNWに参加することになったのは地元のリチャードさんがBEAR.Sundayを気に入って彼が応募し採択され共同発表する事になったからです。 その年のphpcon(東京)への応募は落選してて、初めてカンファレンスに登壇したのは日本ではなくPHPNWでした。

知り合いも沢山できて「今年は来てないの?」と前年に言われ参加したのが最後のphpnw17でした。

PHPNWとはどういうカンファレンスだったか改めて振り返ってみます。

参加者、特にスピーカーにオープンソースの開発者が多かったです。XdebugのDerickさん、phpDoumentorのMikeさん、ReactPHPのCeesさん、ZF/SlimのRobさん、Silex/YoloのIgor さん、BeHatのEverzetさん、HHVMのSaraMGさん、あげればきりがないくらい沢山います。私が気が付いていない人もいたでしょう。しかし有名オープンソースの開発者が必ず登壇してるという風でもなく聴衆としても参加してます。他にはDDDやBDDのエバンジャリストや、コミュニティリーダー、アプリケーションアーキテクトとかそういう人が登壇してる感じでした。

参加者のソーシャルを大事にするカンファレンスでした。ブレイクは25分と長く、スピーカーの話を聞く&参加者とおしゃべりをするサイクルができています。スピーカー同士の交流が生まれやすいように、スピーカーディナーやランチなどスピーカー同士のソーシャルができる場も用意されていました。

スピーカーに対する負担を少なくするため、スピーカー1人につき"shadow"と呼ばれるスピーカーをサポートする人が一人つきます。発表当日の朝、一人の人が現れ「僕は今日あなたのshadowを務めるものです。」と挨拶がありました。かっこいい(!)機材や進行の確認、色々な疑問はshadowに投げると答えてたりshadowが分からないことは 他の人に訪ねてくれます。スピーカーがそれぞれの担当の人を探す必要がありません。

オーガナイザーのジェレミーさんに聞くと「スピーカーの人にはこのカンファレンスで話して良かったと思ってもらいたいんだ。このマグカップのギフトもその工夫の1つなんだ」と教えてくれました。

unconf

誰でも最初から流暢なトークができるわけではありません。人前で話すことに慣れてない方もいます。アンカフレンスはそういう方のためのものでもあります。トークの後にトークについてのレビューやアドバイスもしてくれます。私は最初にセッション枠で登壇して、次からunconfに参加で順番逆だと思うのですが、良い取り組みだと後で知りました。ちなみに担当の人によると、ほとんどのトーク初心者は緊張して喋りが早すぎてしまうという事でした。ゆっくり話しましょう。

どういうトークが採択されているか

トーク応募の項目には発表の概要と共に「なぜ、聴衆は貴方の話を聞かなければならないのか?」という項目があります。聴衆が時間とお金を使って聞く価値があるものを応募してほしい、その視点が無いものは我々は採択しないというメッセージです。トークのゴールを明確にする事で、採択者への理解の助けにもなるでしょう。そして地元の参加者をエンカレッジするために地元の人が優先です。開発者なら誰でも知ってる外国の有名なフレームワーク開発者でも落選していました。採択率は15%程度で高くありません。採択者は4人いて、全員8/10以上のスコアのついたものでなければいけないです。

トーク内容は、アーキテクチャ、エンジニアのキャリア、プログラミング、セキュリティ、CI、QA、API、パフォーマンスなどは多岐に渡ります。 一方、特定のツールの使い方や最新情報、フルスタックのフレームワークの話などはあまりありません。

フレームワーク

何人かに聞いた範囲ではUKではSymfonyが多そうでした。しかし事前にリチャードさんに聞いてた通りフレームワークへの関心は低くあまり話題になりません。結局、使用者がそれぞれの価値観で使ってる印象でフレームワーク特有の話がしたい人はLaraconやSymfony Liveに行ってるのだと思います。

スピーカーに限るとアーキテクトの方が多くフルスタックフレームワークよりそれぞれの問題領域に合わせてコンポーネント志向のフレームワークやインハウスフレームワークを作成している方が多い印象がありました。価値観それぞれで、道具の選定に多様性を感じました。

Sayonara PHPNW

アイデアやインスピレーションに繋がる話が好まれるとも聞きました。道具の作り方や問題の考え方、ソフトウエアパラダイム、コーディング技術、コミュニティやオープンソースへのコントリビュートのトークなどです。自身の取り組んだアプリケーション設計や、自らが参加しているオープンソースの話も少なくありませんでした。私は技術だけでなく、その人がどのように取り組んで来たかというストーリーのある話が好きで、PHPNWは正にその期待に答えてくれる場所でした。

開発する人をインスパイアするためのカンファンレンスというものであったと思うし、unconf含め3回登壇した時もそのつもりで挑みました。

思い出深いカンファレンスが無くなってしまったのは残念です。それがどういうものであったか国内のカンファレンスを運営してる人や参加者、これからコミニュティを運営しようとしている人にインスピレーションを与えることができたらと思い、また自分の記録としてこの記事を書きました。

Re: BEAR.Sundayをコードリーディングしたのでメモ程度にアウトプットする

| Comments

このエントリーは OTOBANK Engineering BlogのBEAR.Sundayをコードリーディングしたのでメモ程度にアウトプットするのReplyエントリーで、コードリーディングを補間する内容です。(@kaliboraさん、ブログ記事ありがとうございます。)

元記事と合わせてお読みください。

3つのエントリポイント

何はともあれ開始地点であるエントリポイントを見てみます。 webからのアクセス用と、CLI用とで3つありました。 それぞれの違いは単純にコンテキストを変えているだけ。 そして bootstrap.php を呼んでいるのみ。

エントリポイントではコンテキスト($context)を指定してbootstrap.phpファイルを読み込みます。

3つのファイルは単に例としてあるだけなので、使用してないファイルは削除しても構いません。同様に新しいコンテキストファイルを追加するのも自由です。

条件を指定することもできます。例えばURIが/api/で始まるパスの時にはAPIとしてJSONを返し、その他はHTMLで返すサービスの時はこのようにします。

Webコンテキストによるアプリケーションコンテキストの変更
1
$context = strpos($_SERVER['REQUEST_URI'], '/api/') !== false ? 'hal-api-app' : 'html-app';

bootstrap.phpでは何をしているのか? このように非常に短いスクリプトで全体の流れを記述しているのみ。

解説されてるようにスクリプト全体を記述しています。さらに短く記述するとこのようになります。

bootstrap.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$context = PHP_SAPI === 'cli' ? 'cli-hal-app' : 'hal-app';

$app = (new Bootstrap)->getApp('MyVendor\MyApp', $context);
$request = $app->router->match($GLOBALS, $_SERVER);
try {
    $page = $app
        ->resource
        ->{$request->method}
        ->uri($request->path)($request->query)
        ->transfer($app->responder, $_SERVER);
    exit(0);
} catch (\Exception $e) {
    $app->error->handle($e, $request)->transfer();
    exit(1);
}

バッチ処理ならルーターも不要なのでこのようになります。

ミニマムなブートストラップコード
1
2
3
4
5
6
7
8
9
10
11
try {
    (new Bootstrap)->getApp('MyVendor\MyApp', 'prod-cli')
        ->resource
        ->post
        ->uri('/path/to/command')()
        ->transfer($app->responder, $_SERVER);
    exit(0);
} catch (\Exception $e) {
    $app->error->handle($e, $request)->transfer();
    exit(1);
}

さらに短く。単にコンソールでechoする出力で例外処理も不要なら一行になります。

一行ブートストラップコード
1
2
3
4
5
echo (new Bootstrap)
->getApp('MyVendor\MyApp', 'prod-cli')
->resource
->post
->uri('/path/to/command')();

複数のアプリを組み合わせた出力を得たい場合には以下のようにできます。

複数アプリを統合
1
2
3
4
$name = (new Bootstrap)->getApp('MyVendor\MyApp1', 'prod-cli')->resource->get->uri('/user')('id' => 'bear')['name'];
$role = (new Bootstrap)->getApp('MyVendor\MyApp2', 'prod-cli')->resource->get->uri('/role')('id' => 'bear')['role'];

echo json_encode(['name' => $name, 'role' => $role]);

アプリケーション全体を実行するスクリプトがフレームワーク本体にではなく、アプリケーションにあるので自由にカスタマイズできます。

$app とは何者なのか?

$appオブジェクトグラフのルートオブジェクトです。

オブジェクトグラフとは何でしょうか?

オブジェクト指向のアプリケーションは相互に関係のある複雑なオブジェクト網を含んでいます。オブジェクトはあるオブジェクトから所有されているか、他のオブジェクト(またはそのリファレンス)を含んでいるか、そのどちらかでお互いに接続されています。このオブジェクト網をオブジェクトグラフと呼びます。

DIのベストプラクティスとしてGoogleのGuiceでは以下の方法を勧めています。

Your code should deal directly with the Injector as little as possible. Instead, you want to bootstrap your application by injecting one root object. The container can further inject dependencies into the root object’s dependencies, and so on recursively. In the end, your application should ideally have one class (if that many) which knows about the Injector, and every other class should expect to have dependencies injected.

開発者のコードは、可能な限りInjectorを直接使うのを避けなければなりません。代わりに、1つのルートオブジェクトを注入してアプリケーションをブートストラップします。このルートオブジェクトのクラスは、依存する他のオブジェクト($app->router$app->resourece)を取得するためのDIする必要がり、依存するオブジェクトのクラスも同様に依存するオブジェクトのためのDIが必要です。 その代わりにルートの一つのオブジェクトに注入します。コンテナは、依存関係をルートオブジェクトの依存関係に注入を再帰的に行うことができます。 あなたのアプリケーションはInjectorについて知っている1つのクラスだけを持つのが理想です。その他のすべてのクラスは依存関係を注入することを期待するべきです。

オブジェクト網の一番最初のルートのオブジェクトが$appです。

可能な限りインジェクターをユーザーが直接使うことを避けるべきです。ライブラリにおいてもインジェクターを知るクラスを原則無しにします。ユーザーがコンテナを直接操作するのはDIではなく、アンチパターンのサービスロケーターです。(オブジェクトは他のオブジェクトの依存になっているのでで、通常のサービスクラスはユーザーがコンテナを触らずともDIで取得できるはずです。)

BEAR.Sundayでは基本2箇所だけ。ルートオブジェクトを生成するBootstrapとリソースを生成するためのファクトリークラスです。

bootstrap.phpではその$appのプロパティだけを使ってアプリケーションを実行します。

リソースオブジェクトリクエスを埋め込む@Embedの機能は実質リソースオブジェクト(ResourceObject)のDIです。@Embed@Linkを使うとリソースファクトリーのコードを使うことなくルートの$appの取得の時のみインジェクターが利用されます。ResourceObject内では$this->resource->uri()でリソースオブジェクトを生成するより、@Embedでインジェクトすることを考慮してみましょう。

AppInjector? AppInjector::getInstance() メソッドでは、指定したinterfaceに束縛されたインスタンスを、依存解決済みで返してくれる。

アプリケーションの名前コンテキストとインターフェイス(また抽象クラス)指定すると、インスタンスを取得することができるのがAppInjector(アプリケーションディペンデンシーインジェクター)です。 BEAR.Sundayでは複数のアプリケーションがそれぞれ名前空間を持ち同時に存在できます。

AppInjectorはプロダクションコードでは(Gooogle Guiceのベストプラクティスの通り)Bootstrapで一度使われるだけですが、テストに有用です。

無名クラスを使って以下のように、モックやスタブを束縛することができます。

無名クラスで上書き束縛
1
2
3
4
5
6
7
8
9
10
11
12
13
public function testAnonymousClassBinding()
    $injector = new AppInjector('FakeVendor\HelloWorld', 'hal-app');
    $module = new class extends AbstractModule {
        protected function configure()
        {
            $this->bind(FooInterface::class)->to(Foo::class);
        }
    };
app');
    $index = $injector->getOverrideInstance($module, Index::class);
    $name = $index(['id' => 1])->body['name'];
    $this->assertSame('BEAR', $name);
}

http://bearsunday.github.io/manuals/1.0/ja/test.html

(最初の1回目の場合は、依存解決したものをすべてフラットなPHPファイルとしてダンプする。これをコンパイル処理と呼んでいるみたい)

全ての依存ファイルのファクトリーコードは生のPHPファイルとしてダンプされます。インターフェイスだけで作られたシステムは、実際にどのオブジェクトがどのように生成されるか明らかにするのが難しい場合がありますがファクトリークラスを見れば明らかです。シングルトンかプロトタイプかも確認できます。詳細はDIのデバックをご覧ください。

$contexts = cli-hal-api-app であればMyVendor\MyPackage\Module\AppModule…の順番で読み込まれる。しかし優先順位はその逆である。

これはGoFのデコレーターパターンです。最初にAppModuleで束縛されたDIとAOPの設定を外側で"デコレート" 変更しています。

モードで振る舞いを変更するのではなく、後読み優先のモジュールで束縛したクラスを変更して振る舞いを変えています。 cli-hal-api-appであればAppModuleでされている束縛はその後のApiModuleCliModuleで変更することができます。

1
2
3
4
5
6
7
public function foo()
{
  $isDebug = Config::get('app.debug');
  if ($isDebug) {
    $this->logger->log($text);
  }
}

などとメソッド内でモードを判定して、振る舞いを変えるのではなく

1
2
3
4
5
6
7
8
9
public function __construct(LoggerInterface $logger)
{
  $this->logger = $logger;
}

public function foo()
{
  $this->logger->log($text); // 開発以外は何もしないNullLoggerが束縛されている
}

上記のようにLoggerInterfaceに対する束縛をモジュールで変更します。条件や状態を少なくすることは、コード品質の向上に役立ちます。

$requestとは? HTTPリクエストから、BEARで扱う形式への変換、マッピングというのがこの処理の肝なのではないだろうか。

その通りです。WebリクエストをPHPリクエストに変える(ディスパッチ)のためのルーターの結果の値オブジェクト RouterMatchです。

$requestには$method$path$queryの値が保存されています。$pathがリソースクラスに、$methodがリソースクラスのメソッドに、 名前付き引数(named parameters)の$queryがPHPの(順序)引数(oredered parameters)に変換されます。

リソースクラスではWebコンテキスト($_SERVERなどの値)がどのようになってるかを調べ回るようなコードは避けるべきで、リソースクラスの外側でWebコンテキストの値を全て単なるPHPの値に変換しておきます。そうすることコンソールとWebのどちらでも実行が可能でテストが容易なコードになります。

1
$page = $app->resource->{$request->method}->uri($request->path)($request->query);

$pageとは?

1
> $page = $app->resource->{$request->method}->uri($request->path)($request->query);

元記事で順番に辿ってる通りです。

1
> $resource = $app->resource; // BEAR\Resource\Resource

リソースクラアイントが取得され

1
$resource = $resource->get; // BEAR\Resource\Resource

getリクエストをプロパティとして保存します

1
$request = $resource->uri('app://self/path/to'); // BEAR\Resource\Request

uri()はリクエストオブジェクトののファクトリーメソッドです。

1
$page = $request('key'=> 'value', 'hoge' => 'fuga']); // BEAR\Resource\ResourceObject

リクエストオブジェクトは__invokeを実装しているので関数のように直接実行できます。__toStringメソッドも実装しているので文字列評価すると文字列になります。この時の文字がはリソースの状態の表現(representational resource state)です。

今回のまとめ $app が面白いですね。全部そこにまとまっているっていうのが。

$appはアプリケーションはシリアライズ可能でプロダクションではキャッシュされて実行されます。 1つのオブジェクト網なのでビジュアライゼーションも可能です。

$app(http://koriym.github.io/print_o/v1/libs/bear.sunday.html)

$appのビジュアライゼーション

var_dump()などでは表現できないシングルトンオブジェクトなども表現できていることに気づかれるでしょう。重大なエラーが発生した時にバックトレースばかりでなく、/var/log/フォルダにあるログで$appがどのように生成されているかを確認することもできます。

アノテーションやDI、codegenを用いたAOPコード作成など膨大な本来は膨大な初期化コストがかかりますが、$appを1つのオブジェクトとして保存することによりパフォーマンスの問題を解決しています。ResourceObjectも全てが最初にコンパイル(ファクトリーコードの生成)されるので、依存解決の問題がプログラムの途中で発生することがないと言うメリットもあります。

An Interface as an API

| Comments

For extensions, I encourage you to copy entire class and modify it. Does this sound too wild ? Here are my thoughts.

Suppose we make a protected method for future modification. Is this a symptom of violating SRP? If we separate the “extensible concern” and “core concern”, why not separate them as extensible dependency objects in order to conserve SRP?

Yes we loose the some convenience. But a true DI system give us more flexibility with ease. Inherited modification needs hard coded relationships. The modifications and the original class become tightly coupled. In other words, modification of dependency object injection can be done by context and we can then draw the object graph more freely.

Just conform to DIP, seriously….

An ‘unchangeable public methods and no protected method policy’ encourage us to use the final keyword. This helps makes the class stable and closed. The @api annotation may then be needed less.

– moved from http://koriym.tumblr.com/post/66663678471/an-interface-as-an-api (11 Nov 2013)

PHP7.0.0

| Comments

2011年

今から4年前の2011年12月17日(土)に東京で「PHP Apocalypse」なるイベントが開催されました。

http://labs.gree.jp/blog/2011/12/4367/

タイトルが示すようにちょっと変わったイベントでした。 冒頭のセッションで「PHPに未来を感じるか?」という問いがあり、周りを見回すと参加者で手をあげてるのはなんと自分一人。 その時のエントリーがあります。

PHP: Dis Is It. http://koriym.github.io/2011/12/php-dis-is-it/

PHPはカリスマがいない。特定のイデオロギーを持たず、変化に躊躇がない。 漸進的な進化を継続可能でそれを実践するものには未来がある。そう考えたのです。 よく問題とされることは単に詳細の話で深刻なものではないとも考えました。

そして4年が経ちました。

サーバーサイドの言語で80%のシェアを持ち、エコシステムは大きく前進し、言語もPHP5.4(2012年3月)、PHP5.5(2013年7月)、PHP5.6(2014年8月)と高い互換性を維持しつつバージョンアップを繰り返し2014年にはFacebookのPHP"Hack"も公開されました。未来がないどころではなく、 composerの登場もありました。言語もPHPコミュニティもエコシステムも全てがこの4年で大きく進化しました。

そうです、未来がないと考えた参加者の予想は見事なくらい大外れしたのです。

# PHP 7.0.0

そして本日2004年以来のメジャーバージョンアップ7.0.0がリリースされました! 素晴らしい!!おめでとうございます!!!

先日米国ワシントンで開催されたPHP Worldのアンソニー・フェラーラさんによる基調講演PHP7 and Beyond: The Future of PHP をYouTubeでみました。 その中で「Victory for PHP」と話します。「PHPはプログラムを始めたばかりの初心者から、大企業のシニアまで、最小のWebサイトから世界最大級のサイトまで全ての人に力を与える。 特定のイディオマティックなプログラミングパラダイムを押し付けることもない。ユーザーは選択可能で、可能な限り"“許される"PHP。」

そして以前アンドロイドのAdキャンペーンで使われていた言葉を紹介します。

”Be together, Not the same" https://www.youtube.com/watch?v=vnVuqfXohxc

皆が同じになる必要はない。それぞれが違うアイデンティティを誇り、尊重しあい、しかし一緒に進もう。 多様性を乱立と呼び問題視するのではなく、相互に影響しあってコミュニティ全体を前進させるための仕組みと考えましょうと。 素晴らしい!小さなプロジェクトにずっと取り組んでいる身に響く言葉です。

PHP7のリリースおめでとうございます! 多様性を享受し高い互換性を維持しながらコミュニティドライブで変化を続けていくPHP。未来は開けてます!!

再度質問「PHPに未来を感じますか?」

YES YES YES !!

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

| Comments

2015/06/27 10:20AM 福岡FFB HALL

 

PHP20周年

福岡で初めてのPHPカンファレンスが開催され、その基調講演を行う機会をいただきました。 今年はPHPが生まれて20年の記念すべき年です。アニバーサリーに行う講演ということでPHPの"真ん中"は何処から来たのか、そのオリジンを問いそして祝福するような話をしたいと考えました。

ちょうど一年前の6月28日(福岡は6月27日!)に去年のPHPカンファレンス関西が行われ、同名のタイトルの講演全てを結ぶ力を行ったのですが、 今回も沢山の方に聞いていただきました。ありがとうございました。

基調講演に続いて小ホールで直ぐに「YOUR.Sunday」という講演をしました。後ろは立ち見でびっしり、会場から人が溢れそうなくらいの方に聞いていただきました。 聴衆との距離が近い小ホールには一体感があって良かったと思います。

全てを結ぶ力

当初講演内容がなかなか決まらず、BEAR.Sundayのチームの人や@cakephperさんには度々相談しました。二つ案を考え、結局どちらもすることになりました。 基調講演の直前のリハーサルはエキサイトの人達に協力していただきました。福岡入りしてからもYOUR.Sundayのことで@kuma_nanaさんや@madapajaさんにアドバイスいただきました。 みなさん、ありがとうございました。

最初の開催ということで大変なことも多かったと思いますが、スタッフの方たちの工夫や熱意が伝わりました。主催者、登壇者、聴衆、それぞれの参加者の距離が近く、皆で作りあげたカンファレンスだと感じました。 PHPの生まれた1995年を懐かしいという人もいたし、PHPと自分は同い年だという人もいました。それだけ年齢が違う人々が集まり、多様な人たちが結ばれている場でした。「全てを結ぶ力」はここでも働いていたのです!

HaPHPy Birthday PHP

| Comments

HaPHPy Birthday PHP, 20 years old today !

PHP 20周年おめでとう!

今から20年前の6/8日にPHPのクリエーターのRasmusさんが 初めてPHPを"Personal Home Page Tools"としてソースコードを共有しました。

世界の82%のWebサイトがPHPで動いてます。20周年おめでとう!おめでとう!!

こんなおめでたい日にお知らせがあります。今月27日に開催される記念すべき第一回のPHPカンファレンス福岡の基調講演をすることになりました。 タイトルは「全てを結ぶ力」です。

基調講演の他に25分のセッションも行います。こちらのタイトルは「YOUR.Sunday」です。

Excited to announce I’ll be giving the opening keynote at #phpconfuk15 !

福岡でお会いしましょう。よろしくお願いします。 ( ´ ▽ ` )ノ

First BEAR.Sunday Stable Release !

| Comments

BEAR.Sundayの初めてのstableバージョンをリリースしました。

たくさんの方々にお世話になりました。@mackstar 日本と欧米の開発事情に精通していて様々なアドバイスをいただきました。 リチャードさんのアドバイスは一貫して、「無駄を省いていく」というもので日本人以上に日本人なZenの心も持ち主です。彼のおかげでイギリスのカンファレンスで登壇することもできました。

Lithium開発者@nateable さんは私が初めて会ったフレームワーク設計者です。様々な質問を伺い刺激になりました。 その後、今度は海外のカンファレンスで何度もBEAR.Sunday私自身を紹介してもらって、 BEAR.Sunday開発の継続する自信にもなりました。 CakePHP3のコアディベロッパーの @jose_zapさんはCakePHP3のORMのモジュールを提供してくれました。Ray.Diを実務で使用されていて様々なフィードバックをいただいてAOP使用例も参考になりました。

初期の頃の試みとしてPHPメンターズの @hidenorigotoさん、 @iteman さん、array syntax@rskyrsky さんとオンラインmeetupでその時の「これからの野望」を色々聞いて頂きました。またリアルなmeetupは@NEKOGET, @brtriver, @kuma_nana, @zumkimochi, @zingooo さん他お世話になりました。参加してくれたみなさんもありがとうございました。 Symfonyユーザー会でも何度もお話させていただきました。(BEAR.Sundayしかなかった回がありました!)OAuthModuleのモジュールをかいてくれた @kawanamiyuu さん、TwigModule@madapaja さん、FakeModuleの @shingo-kumaagi さん 0.x版でPHPtalの@tanakahisateruさん。BlogやQiitaでBEAR.Sundayの記事を書いてくれたカルテットコミュニケーションズの @qckanemoto さんや @77web さん  イラストをかいてくれた @tdakak さん、ベア吉ステッカーで協力してくれたshimadaさん、reikoさん エキサイトの @usomillp さん、@gokigendoriさん、iwafujiさん、fukushimaさん、kobayashiさん、toshinaiさん他 BEAR.Saturdayの時からずっとBEARのファンでいてくれる @ryo88c @zingooo TOM さん 大勢の方にコードやアイデアのコントリビュートをいただきました。@iteman にはフレームワークの拡張点として視点、 @mugesoさんや@kenji_sさんにはいくつものPR、 @hidenorigotoさんには雑誌で紹介していただきました。@kuma_nanaには音声入りの画面チュートリアルをつくってもらいました。

海外の方にもお世話になりました。Guiceの使用経験もないのにRay.Diをつくっていた私に@akkieは色々と教えてくれました。 @craigjbassとのディスカッションはRay.Compiler誕生のきっかけになりました。@auraphpには大きな影響を受けいくつもの指針を得ました。 リードの@pmjonesさんや精力的に活動されている@hariktさんに感謝したいと思います。

下記はGitHubでのコントリビューターリストです。meetupに参加してくれた方、ブログ記事を投稿してくれた方、フィードバックをくれた方、ベア吉の好きな人、関心をもってくれた方全ての方に感謝します。 これからもよろしくお願いします。

http://bearsunday.github.io/

akkie mackstar zukimochi yuya-takeyama yutakachiba yoshikitanaka

vlakarados tomverran tanakahisateru shingo-kumagai sasezaki remore

qckanemoto nishigori nateabele MugeSo malukenho madapaja

lorenzo kyanny kumamidori ktutumi kenjis kenchingh

kawanamiyuu kaepapa jingu jamolkhon iteman holyshared

hidenorigoto harikt fivestar fiahfy desigrammer craigjbass

bar atakig 77web

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

| 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にも会えました。