シンプルなテンプレートエンジンPlatesをSilexで使ってみる
Platesという、シンプルなテンプレートエンジンを使ってみた。 小さなWebアプリケーションでTwigが必要なほどではない場合にはちょうど良いと思う。
まずはSilexで最低限のものを実装しよう。
{ "require": { "silex/silex": "~1.3" } }
<?php // web/index.php require_once __DIR__ .'/../vendor/autoload.php'; $app = new Silex\Application(); $app->get('/', function () { return "Hello"; }); $app->run();
Getting Started
composer.jsonにPlatesを追加してcomposer updateする。
{ "require": { "silex/silex": "~1.3", "league/plates": "3.*" } }
では最低限の実装を。
<?php // web/index.php require_once __DIR__ .'/../vendor/autoload.php'; $app = new Silex\Application(); $app->get('/', function () { $templates = new League\Plates\Engine(__DIR__ . '/../templates'); return $templates->render('home', ['title' => 'Hello']); }); $app->run();
<!-- templates/home.php --> <h1><?=$this->e($title)?></h1>
見ての通り、テンプレートエンジンというよりほぼPHPそのままだ(まあそもそもPHPってそういうものなんだけど)。 PHPにテンプレートエンジンとして使うための便利機能を追加したもの、と考えた方がいいかもしれない。
ルートのアクション内でEngineをnewするのはあんまりなので改善しよう。行儀よくやるならServiceProviderを使うのかもしれないけどここはより単純に、単にコンテナに追加してしまおう。
<?php // web/index.php ... $app['view'] = $app->share(function () { return new League\Plates\Engine(__DIR__ . '/../templates'); }); $app->get('/', function () use ($app) { return $app['view']->render('home', ['title' => 'Hello']); });
Silexのバージョンは1.3.0で、Pimpleが1.1.1なので$app->share()
を使っている。
layoutとinsert
もう少し色々試してみたいんだけど、ネタがないと難しいのでRails Tutorialの静的ページ部分を借りてくることにした。詳細は省くがnpmでbootstrap-sassをインストールし、gruntでビルドできるようにした。
さてレイアウトを導入しよう。
<!-- templates/home.php --> <?php $this->layout('layouts/application', ['title' => 'Home']) ?> <div class="center hero-unit"> <h1>Welcome to the Sample App</h1> <h2> This is the home page for the <a href="http://railstutorial.jp/">Ruby on Rails Tutorial</a> sample application. </h2> </div>
<!DOCTYPE html> <!-- templates/layouts/application.php --> <html> <head> <title><?=$title?></title> <link rel="stylesheet" type="text/css" href="app.css"> <?=$this->fetch('layouts/shim')?> </head> <body> <?=$this->fetch('layouts/header')?> <div class="container"> <?=$this->section('content')?> <?=$this->fetch('layouts/footer')?> </div> </body> </html>
$this->layout()
でレイアウトを指定し、$this->section()
で呼び出している。$this->section()
の引数はセクション名で、content
は全ての出力を表す唯一の予約済みのセクション名だ。
明示的にセクションを作る場合は $this->start('name') ... $this->stop()
を使う。
$this->layout()
でレイアウトを指定すると同時にtitleも渡しているので、index.php側からはtitleを渡す必要は無くなった。
$app->get('/', function () use ($app) { return $app['view']->render('home'); });
<?=$this->fetch('layouts/shim')?>
は<?php $this->insert('layouts/shim')?>
と書くこともできる。
full_titleヘルパー関数
手順は前後するけど、Rails Tutorialの中にfull_titleというヘルパー関数が出てくるのでこれを実装してみよう。
<?php // web/index.php ... $app['view'] = $app->share(function () { $engine = new League\Plates\Engine(__DIR__ . '/../templates'); $engine->registerFunction('full_title', function ($title) { $base_title = 'Ruby on Rails Tutorial'; if (empty($title)) { return $base_title; } return "$base_title | $title"; }); return $engine; });
<!-- templates/layouts/application.php --> <html> <head> <title><?=$this->full_title($title)?></title> <link rel="stylesheet" type="text/css" href="app.css"> <?=$this->fetch('layouts/shim')?> </head> ...
以下のようにtitleに空文字以外を渡すと、Ruby on Rails Tutorial | Home
と表示され、
<!-- templates/home.php --> <?php $this->layout('layouts/application', ['title' => 'Home']) ?>
titleに空文字を渡すと、Ruby on Rails Tutorial
と表示される。
<!-- templates/home.php --> <?php $this->layout('layouts/application', ['title' => '']) ?>
ところで、titleはエスケープして出力したほうが良いだろう。つまりfull_titleを通してからescapeすることになる。 これにはいくつかやり方がある。
<?=$this->e($this->full_title($title))?> <?=$this->batch($title, 'full_title|e')?> <?=$this->e($title, 'full_title')?>
1つ目は説明するまでもないだろう。2つ目の $this->batch()
は、第二引数に複数のヘルパー関数名を |
で繋いで記述することができ、
これらが左から順番に実行されるというもの。3つ目も同じような意味で、$this->e()
関数のみ、$this->chan()
と同様に
第二引数に複数の関数名を|
で繋いで記述することができ、そして最後にエスケープが行われる。
titleのデフォルト値
またちょっと戻るのだけれど、titleを表示したくないときに、
<!-- templates/home.php --> <?php $this->layout('layouts/application', ['title' => '']) ?>
とやるのはちょっとカッコ悪い。しかしなにも渡さないと Undefined variable になってしまう。 レイアウト側でデフォルトを指定する方法も無くはなさそうだけど不格好なので、 Engine 側でデフォルト値を指定してしまおう。
<?php // web/index.php ... $app['view'] = $app->share(function () { $engine = new League\Plates\Engine(__DIR__ . '/../templates'); $engine->addData(['title' => '']); ...
こうすると、全てのテンプレートで title
に空文字列がセットされるので、home.php側からはtitleを渡す必要がなくなった。
<!-- templates/home.php --> <?php $this->layout('layouts/application') ?>
OSC2015北海道で「phpspecで学ぶLondon School TDD」という発表をしてきました
見た目を重視してこんなタイトルにしてみましたが、基本的には私が「実践テスト駆動開発」と「phpspec」をどう解釈したか、というような内容になっています。
45分あってもなかなか伝えるのが難しいテーマだったのですが、とりあえず時間厳守はできてよかったです(一部デモを飛ばしてしまいましたが)。
www.slideshare.net
いくつか補足を。
伝えたかったこと(あるいは上手く伝えられなかったかもしれないこと)
- 外から中へ、あるいは依存関係の上から下へ実装することで、上位が下位に要求するものが明確になる。
- setFoo()のような、プライベート変数をセットするだけのメソッドであっても、それは外から観測できる何かに影響を及ぼすはず(影響を及ぼさないのであればそのメソッド自体不要)。その外から観測できるものをモックを使ってテストできるれば、テストのためだけにgetFoo()を追加する必要は無くなる。
QAより
補完について
Specの書き方が特殊なため、Spec内ではIDEの補完がほとんど効きません。調べてみたところ、部分的には@mixin
アノテーションを使って補完させることができるようです。
PhpStorm & phpspec | Dimitrios Savvopoulos
しかし、この先のshouldReturn()
などは補完することができません。
タイプヒントについて
身内でリハをやったときに、「仮実装を作るときに何故タイプヒントを付けてくれないのか」という質問がありました。
// このような仮実装を生成するが public function toHtmlFromReader($argument1) { return '<p>Hi, there</p>'; } // なぜこのようにしてくれないのか public function toHtmlFromReader(Reader $argument1) { return '<p>Hi, there</p>'; }
これについては議論があったようですが結果的にphpspec自体ではRejectされ、extentionで実装されています。
- ciaranmcnulty/phpspec-typehintedmethods · GitHub
- [Question] type hints for generated methods · Issue #230 · phpspec/phpspec · GitHub
雑感
私は主にLaravel方面をWatchしていますが、ここ最近のPHPのフレームワークは、Composer、PSR、PimpleライクなDIコンテナの発明を経て、HTTPからのアプリケーションの分離みたいな方向に向かっているように思います。Laravel方面ではDDD、CommandBus、CQRS、Event Sourcingといったキーワードが注目されているようです。
そしてこれは、Rails likeなアーキテクチャからの決別でもあります(Railsがダメだというのではなく、PHPでRailsの真似をするのは無理があるという意味です)。
このような方向性に、phpspecはマッチしているのではないかなという気がしています。
PostgreSQLで「1時間以内に解けなければプログラマ失格となってしまう5つの問題」の5問目を解いてみた
久しぶりにこういうのやってみました。良い問題。
1時間以内に解けなければプログラマ失格となってしまう5つの問題が話題に
create or replace function eval(expr text, out ret integer) as $$begin execute 'select ' || expr into ret; end;$$ language plpgsql; with op (c) as ( select unnest(ARRAY[ ' + ', ' - ', '' ]) ), a (c) as ( select 1 || op1.c || 2 || op2.c || 3 || op3.c || 4 || op4.c || 5 || op5.c || 6 || op6.c || 7 || op7.c || 8 || op8.c || 9 from op as op1 , op as op2 , op as op3 , op as op4 , op as op5 , op as op6 , op as op7 , op as op8 ) select c from a where eval(c) = 100 order by 1 ;
巨瀬亮一さんの「勝ち自体にはそんなにこだわっていなかった」の意味について
巨瀬さんは将棋電王戦トーナメント(電王戦に出場するソフトを決める予選)の優勝者インタビューでも同様の発言をしている。
第2回 将棋電王トーナメント 決勝トーナメント最終日 決勝・準決勝 - 2014/11/03 11:00開始 - ニコニコ生放送
7:17あたりより
電王戦出場にあたっては、棋士の先生には申し訳ないですが、 そこまで勝負自体にはこだわりはなくて、 コンピューターを使っていかにプロ棋士が強くなって、 プロ将棋のレベルが上がっていくことに貢献できるかということに 私の場合はモチベーションがあるというか、
コンピューターと人間両方強くなっていくというのが、 今後の将棋界のありかたとしては一番良いのではないかと思っております。
将棋のプロを目指し、挫折し、コンピューター将棋の面白さに出会い、電王戦を迎えた巨瀬さんの心境はどのようなものだったか、ちょっと本人以外には想像できないものではないかという気がする。
電王戦がエンターテイメントとして盛り上がっていることは良いことだけれど、すこし煽り過ぎなのではないかと思う。棋士が負ければ「引退しろ」といわれたり、ソフトが負ければ「もう二度と将棋界に関わるな」といわれなければいけないほどのものなのだろうか。
一方で、コンピューターから見た将棋と人間から見た将棋の違いから、改めて将棋というのはどういうゲームなのかということに気づかされることもあって、そこが電王戦の面白さだ。
もう少し冷静にコンピューター将棋と人間との関係を楽しめるようになればいいなと思う。
書初め
<?php $dt = new DateTime("2014-12-27"); $aDay = DateInterval::createFromDateString("1 day"); for ($i = 0; $i < 7; $i++) { echo $dt->format("Y-m-d, o W D"), PHP_EOL; $dt->add($aDay); }
$ php year.php 2014-12-27, 2014 52 Sat 2014-12-28, 2014 52 Sun 2014-12-29, 2015 01 Mon 2014-12-30, 2015 01 Tue 2014-12-31, 2015 01 Wed 2015-01-01, 2015 01 Thu 2015-01-02, 2015 01 Fri
2014年はこんな年でした
気になったこと
phpspec、behat
- 知らないうちにphpspecがすごいことになっていた件 - iakioの日記
- 1つのSubjectに集中せよ - phpspecのコンセプト - iakioの日記
- "Design How Your Objects Talk Through Mocking"を見た - iakioの日記
- Introducing Modelling by Example - BDDの新しいアプローチ - iakioの日記
phpspecには本当に感銘をうけた。他のxUnit Frameworkとはかなり考え方が違うので合う合わないはあると思うけど、 「単純で小さな部品を組み合わせてソフトウェアを作る」という発想は自分の理想に近いなと思った。
今のところQiitaにphpspecについて書いているのは私だけのようだけど。
TypeScript
「あれなんかわかんねーな、ここだけJavaScriptでいーや」みたいな撤退がしやすいところがTypeScriptの良いところだと思う。 変数は型を持たないけど型アノテーションは付けられるよというのが流行りつつあるようだ。 phpではタイプヒント実行時に見てDIとかMockを生成するみたいなのが流行っているけれども、 TypeScriptでも型情報を何か別の用途に使えないかなと思っている。
Brackets
ここ数年、デザイナーとプログラマーがどうやって一緒に仕事をしていくかみたいな話がよくあるけれど、 Extract for Bracketsがその間をいい具合に埋めるツールにならないかなと思っている。 あと、TypeScriptでコード書くときも結構使える。
もっと前はこんな年でした
そもそも本当に個人情報をデータベースに保存していいのか
Kazuho's Weblog: Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
今年最も気になった記事です。
にもかかわらず、ウェブ関連のソフトウェアにおいては同原則を用いずに、安全性の根拠をプログラムにバグがない点に求めるという悪しき慣習が続いています。特に、機能別の権限分離はまだしも、アクセスユーザー別の権限分離については系統だった実施例が非常に少ないという印象をもっています。
たとえば、SQL Injectionに代表されるSQL関連の情報漏洩も、アクセス制御にRDBMSのアクセス制御機構を用いず、アプリケーションプログラム内のSQL(とそのエスケープ)が正しく記述されている点に、安全性の根拠を求めているが故に発生しているわけです注1。
DJBがWebアプリケーションを作ったらどんなアーキテクチャになるんだろうと妄想する。まずリクエスト毎に別のユーザーIDでchrootだろうが、DB周りは難しいな / “Kazuho's Weblog: Heartbleed脆弱性…” http://t.co/FUaKT2a1gI
— ISHIDA Akio (@iakio) April 11, 2014
ここでDJBの名前を出したのは、ずっと前から気になっていたこの記事を思い出したからです(もしかしたら若い人はDJBとかqmailとか知らないかもしれないけど)。
セキュリティに関するいくつかの考察 - qmail 1.0 から十年 (Some thoughts on security after ten years of qmail 1.0)
この中でDJBは、セキュリティホールを無くするための取り組みの一つとして、「信頼されたコードをなくす」というのを挙げています。
「信頼されていない」というのは、 これらの檻の中のコードは — 何をしようと、どんなに悪いふるまいをしようと、 どれほど多くのバグがあろうと — ユーザのセキュリティ要求を 侵犯できないという意味である。
一般的なWebアプリケーションでは、全てが「信頼されたコード」として作られているように思います。
SQL Injectionされないように実装することは当然重要ですが、 SQL Injectionが可能になったくらいですべてのデータが丸見えになってしまうようなアーキテクチャというのは、 Webサーバーをroot権限で動かしているのと同じような危険を冒しているのかもしれません。
例えば原始的なWikiのように、誰でも同じデータを参照できて編集できるようなWebアプリケーションであればこれで問題はありませんが、 現在の多くのWebアプリケーションは、そうではなくなってきています。 にもかかわらず、アーキテクチャは変わっていません。
ではどうするべきなのか。今すぐには解決策は思いつきません。 データベース側で何かをすることが難しければ、レイヤを一つあげて、ORMあたりが常にユーザーの権限を意識するような作りは可能かもしれません。あと詳しく見てませんが最近Googleに買収されたFirebaseなんかは面白そうだなと思っています。