Laravel4 Happy Hacking

2013.05.24Takashi Ohida

LARAVEL4HAPPY HACKING

13年5月29日水曜日

目次

自己紹介

PHP / フレームワーク歴

Laravel4でつくってみた

Laravel4のすごいところ紹介


自己紹介


自己紹介

名前：大日田貴司（オオヒダタカシ）

所属：都内ウェブ系企業

職業：開発、企画

コード書いてません(^_^;)

サービス設計とかUI/UXとか


PHP歴

PHP歴 8年くらい

Python / Rubyとかなんとなくわかる

GAE / Railsとか少し触ったことある

色々あるけどPHPはかわいい


フレームワーク歴

僕がPHPをはじめた頃

外の会社からできるプログラマが手伝いに来て言った

「まずフレームワークをつくりましょう」



「フレームワーク？なにそれ？おいしいの？」



当時はまだRailsなど存在せず

PHP界隈には、JavaのStrutsに影響をうけたフレームワークが出てきた頃かもという時代



フレームワークとは何かがんばって調べた

MVC、アーキテクチャ設計、デザインパターン、etc ...



概念のすべてを理解しきれなかったけど

「フレームワークってなんだかかっこいい！」



二人でフレームワークをつくった

今思えばとても原始的なものだったけど

フレームワークをつくるのはすごく楽しかった

し、勉強になった



そんなこんなでフレームワークに関心を持つようになった



Railsが出た頃さわってみて、超すごい！と興奮した

PHPでいいのないのか

なかった

つくった

Railsのソースを読んでPHPでそれっぽく実装



自作フレームワーカーだったので

CakePHPとか

CodeIgniter / FuelPHPとか

Symfonyとか

ちゃんと使ったことない

自作も大変なのでイイのに乗り換えたい願望



PHP歴 ≒ フレームワーク歴

自作フレームワーク（）

メジャーどころはなんとなく知ってる

けどちゃんと使ったことは無い

まとめ


LARAVEL3


LARAVEL3

去年のちょうど今頃、HackerNewsでみかけた

https://news.ycombinator.com/item?id=4029427




LARAVEL3

シンプルでクリーンな設計思想

軽量だがひと通りの機能は揃っている

拡張性（bundles）もある

が、


LARAVEL3

Staticメソッド多用

新しいフレームワークって色々不安

命名規則が好みではない

function action_index()とか


LARAVEL3

なんか惜しいというか

そんなにビビビッとこなかった

名前はかわいいのだけれど・・・


LARAVEL3

(́・ω・｀)


LARAVEL3

そして、ときは流れ…


LARAVEL4


LARAVEL4

最近、ふと思った

ブログでも書こう

どうせなら自分でつくろう

全然プログラミングしてないし

リハビリもかねて


LARAVEL4

フレームワーク何にしよう？


LARAVEL4

軽量系のフレームワークをいくつか試した

Slim

Silex

Phalcon(micro)

FuelPHP

...


LARAVEL4

Laravel4のベータが出ていた

ので試した


LARAVEL4

3の思い出（使ってないけど）


LARAVEL4

4をみてみたらびっくり

3でイケてなかった点が

悉く「解消」していた


LARAVEL4

もちろん良かった点はそのままに


LARAVEL4

「ららべる子？」

「顔はかわいいんだけど」

「ちょっとおてんばな性格がなぁ…」


LARAVEL4

そんなららべる子と１年ぶりに偶然再開したら


LARAVEL4

かわいらしさはそのままにとても品のよい子に成長していた ...！


HAPPY HACKINGwith Laravel4


HAPPY HACKING

楽しいって何か

書いてて楽しい、嬉しい

ラクに書ける、シンプルで書きやすい

わかりやすい、悩まない

思い通りに操れる


HAPPY HACKING

楽しいって何か

プログラマーズハイ・高揚感

スーパーハカーな気分

マジカルな感じ・支配感

ゆけおれのコードよ


HAPPY HACKING

Laravelにあるもの

しっかりした枠組み

プログラミングを楽しくしてくれる仕組み

プログラミングのレベルを底上げしてくれるような思想


HAPPY HACKING

IoC Containerによるパワフルで賢い依存性解決

シンプルでクリーンな設計思想・記述

軽量で追いやすいコアコード

実績のある基盤（symfony component）

柔軟性、拡張性


HAPPY HACKING

Staticメソッド多用

IoC Container x Facadeにより解決しました

新しいフレームワークって色々不安

信頼と実績のSymfony Componentが基盤になりました

命名規則が好みではない

好みな感じ（PSR-1準拠）になりました

Laravel3のとき気になってたあれらはどうなったのか


HAPPY HACKING

もはやハッピーな感じしかしない


HAPPY HACKING

ということで

Laravel4でブログをつくってみました


POCHIKAポーチカ


POCHIKA

Laravel4でつくった軽量ブログエンジン

データベースは使わず、markdownファイルを変換

jekyll風味（けどstatic file generatorではない）

php的に動的に動作する

キャッシュとかプラグインとか


POCHIKA

使ってる機能

Routing

Config

Controller

Error & Logging

Cache

Events

IoC Container

View / Templates / Blade

Unit Testing

Artisan CLI

まだ使ってない機能

Forms & HTML

Database

Eloquent ORM

Localization

Queues

Mail

Security

Session

Validation


http://github.com/ohida/pochika

POCHIKA




LARAVEL4


LARAVEL4

IoC Container / Facade

Illuminate / composer / symfony components

psr-0(autoload) / psr-1(coding standard)

その他色々パワーアップ

3からの変更点


LARAVEL4

IoC Container... どのように依存性を解決するか

Facade... シンプルで強力なインターフェイス

おまけ：UnitTest

... IoC ContainerとFacadeが必要な理由


IOC CONTAINER


IOC CONTAINER

IoC ... Inversion of Control

制御の逆転


IOC CONTAINER

“The IoC container is at the heart of the entire application and all dependencies are resolved through that.”

Taylor Otwellさん

IoC Containerはアプリケーション全体における心臓部で、すべての依存性を解決します。


IOC CONTAINER

The Laravel inversion of control container is a powerful tool for managing class dependencies. Dependency injection is a method of removing hard-coded class dependencies. Instead, the dependencies are injected at run-time, allowing for greater flexibility as dependency implementations may be swapped easily.

http://four.laravel.com/docs/ioc

LaravelのIoCコンテナはクラス依存性解決のためのパワフルなツールです。DI（依存性の注入）はコードによるクラス解決を取り除き、代わりにアプリ

ケーションの実行時に依存性を注入します。このことにより依存の実装を容

易に入れ替えられるという柔軟性を得ることができます。




IOC CONTAINER

Basic Usage


IOC CONTAINER

$foo = new Foo;


IOC CONTAINER

$foo = App::make('Foo');


IOC CONTAINER

App::bind('foo', function() { return new Foo;});

$foo = App::make('foo');


IOC CONTAINER

$view = new SmartyView;

"

App::bind('view', function() { $smarty = new SmartyView; $smarty->.. return $smarty;});

$view = App::make('view');


IOC CONTAINER

$view = new TwigView;

"

App::bind('view', function() { return new TwigView([ .. ]);});

$view = App::make('view');


IOC CONTAINER

クラスを「直接」呼ぶのではなくIoC Containerを通して「間接的」に呼び出す


IOC CONTAINER

クラスが必要になった時IoC Containerさんがよしなにつくってくれる


IOC CONTAINER

僕：IoCさん、僕がfeedくれっていったらAtomFeedのことですからよろしくですよ

IoCさん：(o e o)アイヨ

～そしてその時がきた～

僕：「feedくれ！」

IoCさん：(o e o)つアイヨ　～【AtomFeed】


IOC CONTAINER

登録App::bind('feed', function() { return new AtomFeed;});

使う$feed = App::make('feed');echo $feed->generate(); //render xml/atom


IOC CONTAINER

登録App::bind('feed', function() { return new RssFeed;});

使う$feed = App::make('feed');echo $feed->generate(); //render xml/rss


IOC CONTAINER

singletonもIoCが解決

App::singleton('foo', function(){ return new FooBar;});


IOC CONTAINER

既にあるインスタンスを登録することも

$foo = new Foo;

App::instance('foo', $foo);


IOC CONTAINER

Automatic Resolution

The IoC container is powerful enough to resolve classes without any configuration at all in many scenarios.

IoCコンテナは強力なので、多くの場合においてクラス解決のために何かをする必要はありません。


IOC CONTAINER

class FooBar {

public function __construct(Baz $baz) { $this->baz = $baz; }

}

$foobar = new FooBar(new Baz);


IOC CONTAINER

class FooBar {

public function __construct(Baz $baz) { $this->baz = $baz; }

}

$foobar = App::make(‘FooBar’);


IOC CONTAINER

class FooBar {

public function __construct(PiyoInterface $baz) { $this->baz = $baz; }

}

IoCさん　(o e o)Interfaceかー解決できねー...orz

なんていうことはなく


IOC CONTAINER

App::bind(‘PiyoInterface’, Poyo);# PiyoInterfaceが呼ばれたらPoyoのことなんだからね


IOC CONTAINER

class FooBar {

public function __construct(PiyoInterface $baz) { $this->baz = $baz; }

}

App::bind(‘PiyoInterface’, Poyo);

App::make(‘FooBar’);(o e o)/


IOC CONTAINER

class Eva {

public function __construct(PilotInterface $pilot) { $this->pilot = $pilot; }

}

App::bind(‘PilotInterface’, ‘Ayanami’)

$eva = App::make(‘Eva’);# get_class($eva->pilot) == ‘Ayanami’


Practical Usage実用例

IOC CONTAINER


IOC CONTAINER

class OrderController extends BaseController {

public function __construct(OrderRepository $orders) { $this->orders = $orders; }

public function getIndex() { $all = $this->orders->all();

return View::make('orders', compact('all')); }

}


IOC CONTAINER

$orders = new OrderRepository();

new OrderController($orders);

App::bind(‘OrderRepository’, ‘MockOrders’)

App::make(‘OrderControler’)

普通に書くとデータベースへの接続が発生

IoCを使うとスタブで置き換えられる


IOC CONTAINER

In this example, the OrderRepository class will automatically be injected into the controller. This means that when unit testing a "mock" OrderRepository may be bound into the container and injected into the controller, allowing for painless stubbing of database layer interaction.

この例では、OrderRepositoryクラスは自動的にコントローラーに注入され

ます。このことは、ユニットテストの際にモックのOrderRepositoryクラスを

コントローラに注入することができ、データベース操作部分のスタブ化が容

易になることを意味しています。


http://four.laravel.com/docs/testing

http://four.laravel.com/docs/testing

IOC CONTAINER

まとめ

IoCとは、Inversion Of Control（制御の逆転）

よしなにクラスをつくってくれる

よしなに依存関係を解決してくれる

テストもしやすくなる


FACADE


Facade（ファサード）とは「建物の正面」を意味する。

(wikipediaより)

FACADE


FACADE

なんの正面か = クラス


FACADE

Page::find('about');


FACADE

Behind the scene


FACADE

class Page {

private static $pages;

public static function find($name) { return self::$pages[$name]; }

}

# なるほどstaticね。Pageクラスの中身はこんな感じかな



FACADE


class Page {

private $pages;

public function find($name) { return $this->pages[$name]; }

}

# ちがうよ。Pageクラスはstaticメソッド持ってないよ


FACADE


Pageクラスではなく、実は

Facadeが呼ばれている


FACADE

Page::method()って書いたら、普通はPageクラスがよばれる

そして ”そのメソッドはstaticに呼べません”

というエラーが出る

Facadeを介すには？


FACADE

Page::method()って書いたら、Facadeの方よんでねとLaravelに教える

app/config/app.phpに書く

aliases = [ ‘Page’ => ‘Facades\Page’,];


FACADE

<?php namespace Pochika\Facades;

use Illuminate\Support\Facades\Facade;

class Page extends Facade { /** * Get the registered name of the component. * * @return string */ protected static function getFacadeAccessor() { return 'page'; // IoC Containerが解決できる名前 }}


FACADE

Page::find(‘about’);

"

Pageファサード

"

App::resolve(‘page’)->find(‘about’);


FACADE

$this->input->get(‘hoge’);

"

Input::get(‘hoge‘);


FACADE

$view = new View;$view->render(‘index.html’);"

View::make(‘index.html’);


FACADE

どこからでも単独で呼び出せる

$thisって誰？を意識しない

誰でもいいしいなくてもいい

疎結合

依存性、コンテキストの排除

統一されたクリーンなインターフェイス

$this->hogeだったりnew Fuga()だったりしない


FACADE

まとめ

Facadeを利用することで、シンプルで強力なインターフェイスでクラスを扱うことができる


FACADE

Laravel4はIoC ContainerとFacadeがキモ

Laravel4使うなら最初に理解するべきポイント


FACADE

Router

Router::get(‘/’, ‘IndexController@index’);

Event

Event::fire(‘post.converted’);

View

View::make(‘index.html’, $payload);


UNITTEST


UNITTEST

テストしやすい/しにくいってなにか

Staticメソッドでテストが難しいのはなぜか


UNITTEST

UnitTestではテスト毎に初期化されることが前提

前のテストの影響をうけるとまともなテストにならない


UNITTEST

staticオブジェクトにはconstructorとdestructorがない

初期化処理と終了処理が行われない

始まりと終わりがない

ひとつのテストによって生じた状態をクリアできない


UNITTEST

function testEach(){ PostRepository::each(function($post) { $post->title .= ‘:hoge’; }); $this->assertHoge(..);}

function testHoge(){ $posts = PostRepository::load(); ↑ testEachの処理を経た状態になっている ..}

class PostRepository {

private static $posts = [];

public static function load() { return self::$posts; }

public static function each ($func) { array_walk( self::$posts, $func ); }

}

テストクラス


まとめ


まとめ

Laravel4は3のときのよさ（クリーンさとか）はそのままに

IoC Containerとかcomposerで中身がおとなになった

テストもしやすい（規模に関わらずテストは必要）

PHPもここまで来たかくらいイケてる感じで書ける


LARAVEL4たのしい☆彡のでみんなつかおう

（自分に合うかは見極めよう）



http://solvalou.net/

http://twitter.com/ohida

http://www.facebook.com/takashi.ohida

http://github.com/ohida

Takashi Ohida


http://solvalou.net

http://solvalou.net







Technology

Laravel4 Happy Hacking