シンプルなテンプレートエンジンPlatesをSilexで使ってみる

Platesという、シンプルなテンプレートエンジンを使ってみた。 小さなWebアプリケーションでTwigが必要なほどではない場合にはちょうど良いと思う。

platesphp.com

まずは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アノテーションを使って補完させることができるようです。

f:id:iakio:20150614155113p:plain

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で実装されています。

雑感

私は主にLaravel方面をWatchしていますが、ここ最近のPHPフレームワークは、Composer、PSR、PimpleライクなDIコンテナの発明を経て、HTTPからのアプリケーションの分離みたいな方向に向かっているように思います。Laravel方面ではDDD、CommandBus、CQRS、Event Sourcingといったキーワードが注目されているようです。

そしてこれは、Rails likeなアーキテクチャからの決別でもあります(Railsがダメだというのではなく、PHPRailsの真似をするのは無理があるという意味です)。

このような方向性に、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あたりより

電王戦出場にあたっては、棋士の先生には申し訳ないですが、 そこまで勝負自体にはこだわりはなくて、 コンピューターを使っていかにプロ棋士が強くなって、 プロ将棋のレベルが上がっていくことに貢献できるかということに 私の場合はモチベーションがあるというか、

コンピューターと人間両方強くなっていくというのが、 今後の将棋界のありかたとしては一番良いのではないかと思っております。

将棋のプロを目指し、挫折し、コンピューター将棋の面白さに出会い、電王戦を迎えた巨瀬さんの心境はどのようなものだったか、ちょっと本人以外には想像できないものではないかという気がする。

電王戦がエンターテイメントとして盛り上がっていることは良いことだけれど、すこし煽り過ぎなのではないかと思う。棋士が負ければ「引退しろ」といわれたり、ソフトが負ければ「もう二度と将棋界に関わるな」といわれなければいけないほどのものなのだろうか。

一方で、コンピューターから見た将棋と人間から見た将棋の違いから、改めて将棋というのはどういうゲームなのかということに気づかされることもあって、そこが電王戦の面白さだ。

もう少し冷静にコンピューター将棋と人間との関係を楽しめるようになればいいなと思う。

www.asahi.com

nlab.itmedia.co.jp

書初め

<?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

Rebuild: 73: It Is 2015 Already (N, naan)

2014年はこんな年でした

  • 初めてTOEICを受験した
  • 将棋ウォーズを始めた。今10切れ4級。これ以上あがりそうにない
  • 初めてコンサドーレの試合を見に行った
  • 個人的にtravisや、herokuで遊んでみた

気になったこと

phpspec、behat

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の名前を出したのは、ずっと前から気になっていたこの記事を思い出したからです(もしかしたら若い人は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なんかは面白そうだなと思っています。