BEAR Blog

Because everything is a resource.

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

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開発者の誰もが知るプロダクトでスピーカーはその開発者、立ち見がでるくらい満員です。

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

(続く)