うまれかわるMVC 〜PHPカンファレンス関西2014にむけて

PHPカンファレンス関西2014リレーブログ11人目です。イレブンです。イレブンといえばワールドカップ観戦で忙しいこの時期ですが、みなさんPHPカンファレンスへの心の準備はいかがですか。サッカー疲れでバテないように、テンション上げていきましょう。

先週は、@tbsmcd さんの『機関区 : カンファレンスで起きる何か』で終わっていました。うまれかわったPHPerのエピソード、涙腺がゆるみますね。今年は、もっと多くのビギナーが最後まで楽しめるように、という構成を意識してみました。まだ勉強会慣れしていない人も、いい意味でショックを受けてもらい、うまれかわり感を持って帰ってもらえたらと思います。

さてタイトルの MVCMVC といえばもちろん Microsoft Visual C++ ですよね。ちがいますね。ごめんなさい。いまどきの PHPer にとっては MVC = Mac, Vagrant, Composer ですね。

Mac:

一時期「勉強会のMac率は異常」みたいな言われようしましたが、もういいかげん馴染んできました。勉強会でMacなのはもう当たり前という空気ができています。Macのメリットってなんだろうと考えると、だいたいこんなところでしょうか。

  • アルミ削り出し筐体が硬い = 持ち運んでも安心
  • 他のOSより修飾キーがひとつ多い
  • キーボードが光る
  • Windowsをインストールできる

...そこじゃないでしょというツッコミが聞こえてきたので追記。

  • いきなり bash が起動
  • はじめから ssh 入り
  • はじめから UTF-8
  • サーバと同じコマンドで操作できる
  • PHPRubyで「Windows特有」の影響を受けなくて済む
  • 電源/外部モニタのコネクタが同じ人が多い
  • 使っている人が多くてノウハウが豊富

というわけで、人と同じのが嫌だというオシャレさんは、Mac以外を選ぶといいですね。あれ? 数年前ってたしかこれ逆でしたよね。よくよく考えると、Macのメリットは単に「サーバと共通だから」「開発者間で共通だから」なんですよね。本質的には、Windowsと立場が逆になっただけで、コミュニケーションというか、インターフェースの問題なだけな気がしています、個人的には。

Vagrant:

Vagrantは、歴史は短いのに、あっという間にWeb開発者の共通語になりました。もっとも有名な、OS仮想化のフロントエンドですね。仮想OSだと、別の人のマシンに自分の持っているものと同じ環境設定を再現できる。もう時代は、開発用共用サーバーにFTPじゃないんです。php.ini がちょっとだけ違うせいで半日トラブルを追いかけていたのが無駄、なんてことはなくなりました。

OSを仮想化してしまえば、NginxだろうとPHP-FPMだろうとNode.jsだろうと未知のRubyGemsだろうと、なんだって入れられます。前の環境に戻せなくなるのが怖くて新しい技術を試せない、なんてことはありませんね。

仮に上のMがMacではなくMicrosoftの人だったとしても、開発ターゲットはみんな同じ仮想OSに揃えられるんです。それも、同じやりかた、vagrant コマンドという共通語で。

Composer:

最近のPHPの世界観にもっとも影響を与えたのがこれです。依存ライブラリのインストール自動化。Composerのおかげで、各クラウドベンダーは、PHPのPaaSを同じルールで提供できるようになりました。もちろんPaaSでなくても、ライブラリのバージョン管理が非常に楽になりました。

楽になりました、というと、「あれ? 昔そんなに苦労していた気がしないけどなぁ」と思うかもしれなませんが、そういうことじゃないんですよ。

昔はzipを解凍するだけオールインワン、あっても追加ライブラリ2〜3個、それでいけるのがPHPの強みでした。が、本当は、世界中の開発者の力を少しづつ集めると巨大企業を凌ぐ信頼性を得られるのが、オープンソースの意義ですよね。オールインワンに依存すると、あらゆる課題を1つのプロジェクトに握られる。1プロジェクトの力はさほど大きくありません。

つまり、楽になった結果として、かつて使われていたよりもはるかに多くの外部ライブラリを使うようになり、以前より設計が多クラス化してくるようになったことがポイントです。ずばり、Composerがなかったら、Symfonyコンポーネントがこれほど受け入れられることもなかったでしょうし、ましてや、名前空間の意義も...。もしいまだに、自分のコードがシステムインストールのPEARと競合して泣いていたなんて考えたら、ぞっとしますね。

あ、そういえば、PHPカンファレンス関西2014の基調講演は、「全てを結ぶ力」だそうです。MVC = (Mac,Vagrant,Composer) は、技術そのものではなく、エンジニアを結ぶ力であることが面白いところでしたね。さてじゃあ「全て」とは何なのか ... 気になりますね。

ご参加お待ちしております。

まじめにやってください

(読者の声: あの、そういう話が聞きたくてこのページ開いたんじゃないんですけど...)

えっ? あ、MVC? モデル・ビュー・コントローラ?

---- あれは ... 夜空の星になりました。えぇ

だいたい、なんで MVC すぐ死んでしまうんでしょうね。これからはMOVEだとか、MVVMだとか、新しいこと言うために毎回やられ役です。生き返ったとは聞いた覚えがないのに、またすぐ死んだって言われちゃう。もうね、いいかげん生きてるとか死んでるとか、そういう次元から解き放ってあげませんか。

MVCは人間とそのメンタルモデルに関するものであり、オブザーバパターンに関するものではない。

DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism

ほら、物理的にどういう形をしているか、とは違う次元の概念って、言い出しっぺの人が言ってるじゃないですか。

モデルの変化がビューに通知されようがされまいが、ナントカControllerに明らかにビジネスロジックを書いていようが、いや、もういっそソースコードを見なくても、画面を持つあらゆるアプリケーションには、

  • アプリケーションの本質を構成する部分
  • 人間に見せるために作られている部分
  • コンピューターシステムにそれらを乗せるがためにどうしても必要なコード

この3つがあるでしょって話ですよ。それらがコード中のどこにどう配置されてようが、存在しないなんてことはありえない。

神話や宗教では、そういうのは、人間や動物の仲間ではなくて、精霊とか神とか言われますね。だからお空のお星様でいいんです。どれだけ人間界が汚れようとも、天界かどっかで永遠に生きてる、現世では実体のない存在。人の無意識にあって正義感の拠り所になっている。MVCはいつも人々の心の中に、それでいいじゃないか、と。

MVC、ぼくたちはきみのことを忘れない、永遠に...

フレームワークごとに、いろいろな形で3つのフォルダに入れられて、いつもどこかでdisられていたね、今となってはなつかしい思い出だよ...

f:id:tanakahisateru:20140622021744p:plain

はいっ、濃い人はこんな感じでテンション上げていきますよ〜。

いよいよ本番は今週末、次は @shin1x1 さん、Shin x blog です。お楽しみに。

Yii2.0-beta v.s. Laravel4.1 ベンチマーク

PHP5.5.13のビルトインサーバーで、Yii2.0-betaのDBアクセスを含めた実装をベンチマークテストしてみました。あ、ベンチマークは意味が無いとかいうのはナシです。

HelloWorldベンチだと、ルーティングとビューのオーバーヘッドを比較するしかできません。簡単にチートできてしまいます。データベース接続などのライブラリをプリロードしている方が不利になってしまいます。Yii1は公式発表のHelloWorldベンチがずば抜けて速かった(曰く、ほとんどのコードは必要になるまでロードされないことを表しているらしい)のですが、そういう部分だけを際立たせて、だから全体が速い/遅いと考えるのはおかしいです。

そこで、postとcommentテーブルを持つ同じデータベースに接続して、postデータを1件とそれに付随するコメントをすべて取得する(実際にはデータが1件だけある)処理を含みました。

比較対象は ... Laravel です。

比較したかった理由:

DBクエリの結果がArrayになる系のものは除外します。またDoctrineは、動的なActiveRecordとは動作特性が違いすぎました。同じ種類のもので比較したいとなったとき、Eloquent ORMがすぐに動くのがLaravelでした。

...という理由はそれほどたいした問題ではないです。

比較したかった真の理由:

Laravelは中身にSymfonyコンポーネントを使っていて、いわば二重の構造になっています。さらに、記述姓のために実行時にメタプログラミング的なトリックをしかけています。

Yii2はパフォーマンスを重視して、コア部分にサードパーティーライブラリの層を持たない方針で設計されています。また、IDEでの生産性も重視しており、その結果、PHPの型システムに素直に従ったコードになっています。

で、まあ、Laravelのほうが遅いのはわかっていて、実はポイントは、この作りの違いがPHPコードキャッシュでどれぐらいの差になって現れるのだろうか、というのを知りたかったというわけです。

テストに用いたデータの構造:

CREATE TABLE `post` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(255) NOT NULL,
  `body` text NOT NULL,
  `created_at` int(11) NOT NULL,
  `updated_at` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_post_category_id` (`category_id`),
  CONSTRAINT `fk_post_category_id` FOREIGN KEY (`category_id`) REFERENCES `category` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `comment` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `post_id` int(11) NOT NULL,
  `body` text NOT NULL,
  `created_at` int(11) NOT NULL,
  `updated_at` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_comment_post_id` (`post_id`),
  CONSTRAINT `fk_comment_post_id` FOREIGN KEY (`post_id`) REFERENCES `post` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Yii2

コントローラ

<?php
namespace frontend\controllers;

use common\models\Post;

class PostController extends \yii\web\Controller
{
    public function actionBenchmark($id)
    {
        $model = Post::findOne($id);
        if (!$model) {
            throw new NotFoundHttpException();
        }

        $this->layout = 'benchmark-layout';
        return $this->render('benchmark', [
            'model' => $model,
        ]);
    }
}

ビュー

<?php
use yii\helpers\Html;

/**
 * @var yii\web\View $this
 * @var common\models\Post $model
 */
?>
<h1><?= Html::encode($model->title) ?></h1>
<p><?= nl2br(Html::encode($model->body)) ?></p>

<ul>
<?php foreach ($model->comments as $comment): ?>
    <li><?= nl2br(Html::encode($comment->body)) ?></li>
<?php endforeach; ?>
</ul>

レイアウト

<?php
use yii\helpers\Html;

/**
 * @var \yii\web\View $this
 * @var string $content
 */
?>
<?php $this->beginPage() ?>
<!DOCTYPE html>
<html lang="<?= Yii::$app->language ?>">
<head>
    <meta charset="<?= Yii::$app->charset ?>"/>
    <title><?= Html::encode($this->title) ?></title>
    <?php $this->head() ?>
</head>
<body>
<?php $this->beginBody() ?>
    <div class="container">
        <?= $content ?>
    </div>
<?php $this->endBody() ?>
</body>
</html>
<?php $this->endPage() ?>

ActiveRecord

<?php
namespace common\models;

use Yii;
use yii\db\ActiveRecord;

/**
 * This is the model class for table "post".
 *
 * @property integer $id
 * @property string $title
 * @property string $body
 * @property integer $created_at
 * @property integer $updated_at
 *
 * @property Comment[] $comments
 */
class Post extends ActiveRecord
{
    /**
     * @inheritdoc
     */
    public static function tableName()
    {
        return 'post';
    }

    // 途中割愛

    /**
     * @return \yii\db\ActiveQuery
     */
    public function getComments()
    {
        return $this->hasMany(Comment::className(), ['post_id' => 'id'])->orderBy(['created_at' => SORT_ASC]);
    }
}
<?php
namespace common\models;

use Yii;
use yii\db\ActiveRecord;

/**
 * This is the model class for table "comment".
 *
 * @property integer $id
 * @property integer $post_id
 * @property string $body
 * @property integer $created_at
 * @property integer $updated_at
 *
 * @property Post $post
 */
class Comment extends ActiveRecord
{
    /**
     * @inheritdoc
     */
    public static function tableName()
    {
        return 'comment';
    }

    // 途中割愛

    /**
     * @return \yii\db\ActiveQuery
     */
    public function getPost()
    {
        return $this->hasOne(Post::className(), ['id' => 'post_id']);
    }
}

Laravel4

<?php

use Illuminate\Database\Eloquent\ModelNotFoundException;

class PostController extends Controller
{
    public function benchmark($id)
    {
        try {
            $post = Post::findOrFail($id);
        } catch(ModelNotFoundException $ex) {
            App::abort(404);
        }

        return View::make('post.benchmark', array(
            'post' => $post,
        ));
    }
}

ビュー

@extends('layouts.benchmark-layout')

<?php
/* @var $post Post 手で追加 */
/* @var $comment Comment 手で追加 */
?>

@section('main')

<h1>{{{ $post->title }}}</h1>
<p><?php echo nl2br(htmlspecialchars($post->body, ENT_NOQUOTES, 'UTF-8')) ?></p>
<ul>
    @foreach ($post->comments as $comment)
    <li><?php echo nl2br(htmlspecialchars($comment->body, ENT_NOQUOTES, 'UTF-8')) ?></li>
    @endforeach
</ul>

@stop

レイアウト

<!doctype html>
<html>
    <head>
       <meta charset="utf-8">
       <title></title>
   </head>
    <body>
        <div class="container">
            @yield('main')
        </div>
    </body>
</html>

Eloquent ORM

<?php

/**
 * @property string $title 手で追加
 * @property string $body 手で追加
 */
class Post extends Eloquent
{
    protected $table = 'post';

    public function comments()
    {
        return $this->hasMany('Comment', 'post_id')->orderBy('created_at', 'asc');
    }
}
<?php

/**
 * @property string $body 手で追加
 */
class Comment extends Eloquent
{
    protected $table = 'comment';

    public function comments()
    {
        return $this->belongsTo('Post', 'post_id');
    }
}

コード比較

Yiiのほうがコードが長いですが、大部分は自動的に生成されたコードです。最初はアセットマネージャー、CSRF対策、Flashメッセージなどがあったのですが、それらがベンチマーク結果に影響しないほうがいいと考え、ビューから取り除きました。それでもまだ、ビューにいくつか謎のメソッドコールがありますが、それはフレームワークの機構との関係が強いため、通常外すことがないものです。そこは最低必要なオーバーヘッドだと考えて残しました。

LaravelはIDE用のdocコメントを追加する手間がありました。ide-helper を使ったのですが、hasMany() の先に orderBy() メソッドがないという警告と、App::abort(404); が例外で脱出するのを理解せずに $post 未初期化の可能性の警告が消せませんでした。それを除けば、コード量は十分少なく、やっていることはダイレクトです。

パフォーマンス比較

ともに、PHPビルトインサーバーで動かします。Webサーバが絡む現実のシステム負荷ではなく、純粋にPHPだけの負荷を際立たせたかったので。

OPCache なし/あり で確認。YiiはDB関連のキャッシュを2段階設けました。LaravelのDBログにテーブル定義を見ている様子がなかったので、Yiiはスキーマキャッシュがあるものが標準だと考えるのがよさそうです。接続は4コアCPUなので4本並列で。

siege -c 4 -t 10S -b -q http://localhost:8082/post/benchmark/2

f:id:tanakahisateru:20140616022654p:plain f:id:tanakahisateru:20140616022721p:plain

OPCacheなし

  • Laravel = 10.16 trans/sec
  • Yii チューニングなし = 14.36 trans/sec
  • Yii DBスキーマキャッシュあり = 18.00 trans/sec
  • Yii さらにクエリキャッシュあり = 18.31 trans/sec

OPCacheあり

  • Laravel = 27.63 trans/sec
  • Yii チューニングなし = 47.91 trans/sec
  • Yii DBスキーマキャッシュあり = 69.53 trans/sec
  • Yii さらにクエリキャッシュあり = 72.86 trans/sec

OPCacheの効果

  • Laravel = 2.7倍
  • Yii チューニングなし = 3.3倍
  • Yii DBスキーマキャッシュあり = 3.9倍
  • Yii さらにクエリキャッシュあり = 4.0倍

OPCacheなしで見ると、やっぱり、2層あるLaravelは、1層のYiiに対して、倍は行かないまでも、それなりの遅さになるなぁという差が出ました。これは、Laravelが、コアの堅牢さをサードパーティに委ねることで、上のレイヤーに開発リソースを割けるのがいいという方針で、自覚して進めた結果ですし、それほど驚くところじゃないですね。

それよりも、注目なのはOPCacheの効果です。OPCacheを入れると何倍速くなるか。Laravelが得るものに対して、PHPの型に素直なコードであるYiiのほうが、より多くを得られることがわかります。コードが予測できれば、ランタイム最適化に有利なのかもしれません。

もし将来、PHPのコードキャッシュがJVMやV8のようなネイティブコードレベルの最適化を推し進めたら、Javaでリフレクションがボトルネックになる的な問題にならないかな...?

PHP関西勉強会でYii2-alphaを試しました

「えー、会場の時間の関係でこの後の人は発表時間2分でお願いします」

という消化不良だったので、Yii2を試した感想を書きます。

http://www.yiiframework.com/news/76/yii-2-0-alpha-is-released/

12月のアタマで、Yii2がようやくアルファ版になりました。パブリックプレビューからずいぶん経ちましたね。あと残るはNoSQLのActiveRecordを作っていろいろ仕上げに入るということで、待ち遠しいきょうこの頃、PHP勉強会で「やり残したことをもくもくしよう」というわけで、どこまで進んだのかをじっさいに見てみました。

まず、プロジェクト作成が Composer で簡単にできるようになっていました。

$ php composer.phar create-project --stability=dev yiisoft/yii2-app-basic testapp

単純な構成のアプリケーションはこれ一発で初期化できます。testappというプロジェクトフォルダができて、要るものが全部入っています。設定などの基本構成もほとんど済んでいます。--stability=dev は安定版がリリース されればなくなるでしょう。

で、いきなりPHPのビルトインサーバで動かすと...

$ php -S localhost:8081 -t web

f:id:tanakahisateru:20131222011602p:plain

いきなりBootstrapじゃん! しかも3がベース。

こんなかっこいい画面が出来上がった状態で始まります。最初から問い合わせフォームとログインフォームが付いているのも健在です。

Yii-Bootstrap チュートリアル - tips - ドキュメント - yiijan.org | Yii日本ユーザグループ

ここもう要らないですね。せっせとBootstrapを入れるためにがんばっていたアレをしなくて済むようになるのは大助かりです。

デフォルトのプロジェクト構造も変わりました。

├── assets
├── commands
├── config
├── controllers
├── models
├── runtime
├── tests
├── vendor
├── views
└── web

protected の中身が出てきた感じです。通常の公開フォルダ web がコードの中にいます。もちろんこれは基本形というだけで、yii2-app-basic 以外にも advanced みたいなマルチサイト向けの構成もあります。で、このプロジェクトのルートが名前空間\app になります。ビューも静的ファイルも上に名前空間のルートがある感じなので、アプリケーションが綺麗にパッケージになってる感じがありますね。

注目すべきは画面の下の方にあるデバッグバーです。Symfonyにあるアレです。リクエストごとの状態やログを見られる機能。面白いのはPHPのバージョン番号が書いてあるところ。

f:id:tanakahisateru:20131222013830p:plain

クリックするとアレがそのまんま!!

f:id:tanakahisateru:20131222013915p:plain

phpinfo(); exit; だけやるアクションをいちいち書かなくてもいいんですよ。わかってらっしゃる。

f:id:tanakahisateru:20131222014310p:plain

Giiも乗りました。GiiはWebブラウザでコード生成できるツールです。

モデルとCRUDを作ってみます。モデルはこれまでと全く同じ感じで作れました。CRUD名前空間をフルに指定する必要がありました。リリースまでにもうちょっと補完が効くようになるんだろうな。

f:id:tanakahisateru:20131222014752p:plain

f:id:tanakahisateru:20131222014804p:plain

レイアウトは main.php 一択になり、2カラムレイアウト用のアクションのメニューはない感じになっています。Yiiの1のときの2カラムレイアウトとアクションメニューって、レスポンシブでモバイルファーストにするとき標準とするにはちょっと邪魔で、自分は外して使っていたんですが、それが基本になったということで、個人的には嬉しい仕様です。

そうそうレスポンシブといえば、Bootstrap3ベースなので何もしなくてもこのぐらいできてます。本当に自動で作ってまだ何もしてないサイトですよ。

f:id:tanakahisateru:20131222015324p:plain

ログインの認証のカスタマイズもわかりやすくなっていました。Yii 1 ではこういうコンポーネントを実装しました。

<?php
class UserIdentity extends CUserIdentity
{
    public function authenticate()
    {
        // ここを書き換えてDBアクセスによる認証など自由に書く
    }
}

Yii 2 はこうです。

<?php
namespace app\models;

use yii\web\IdentityInterface;

class User extends Model implements IdentityInterface
{
    // IdentityInterface を実装する
}

こういう形の User という名前の モデルmodels に置いてあります。それをこう。

<?php
namespace app\models;

use yii\db\ActiveRecord;
use yii\web\IdentityInterface;

class User extends ActiveRecord implements IdentityInterface
{
    public static function tableName()
    {
        return 'user';
    }

    public static function findIdentity($id)
    {
        return self::find($id);
    }

    public static function findByUsername($username)
    {
        return self::find()->where(
            'username=:name', [ ':name'=>$username ]
        )->one();
    }
    // あとは初期実装のまま
}

Model を ActiveRecord にして、必須であるテーブル名とその検索方法を書いたぐらい。

これまでは DB 上でアカウント情報を表すARなモデルを作って、それを CUserIdentity が使うという形で、まあそれでも何でもできたんですが、Yii 2 ではもっと簡単に、モデルとして見えるところにユーザが最初から定義されていて、それをARにするならどうぞ、というわかりやすい感じになっています。

で、ここでもうひとつ驚きがありますね。->model() がなくてクラス自体がリポジトリになってますね。Rails感が増しました。また、findByAttributes()find() + CDbCriteria のどっち使うかがなくなり、引数なしの find() の戻り値がクエリビルダになるからみんな使え、という仕様になりました。

対比してわかりやすいよう Yii1 のコード例を3つ:

User::model()->findAllByAttributes(array(
    'username'=>$username,
));
User::model()->find('username=:name', array(
    ':name' => $username,
));
$criteria = new CDbCriteria();
$criteria->addCondition('username=:name');
$criteria->params = array(
    ':name' => $username,
);
User::model()->find($criteria);

どれ使えと... というのがひとつの様式に統合された感じです。

で、どの形でフェッチするのか、つまり、ARとしてoneか、ARの配列としてallか、単一の値をscalarか、というのを普通に書くというのも、例には出してないですが、CDbCommandの方法との一貫性につながっています。

まああと、PHP5.4以上なので普通にショートアレイが使われていますね。コンパクトでいい感じです。

コントローラまわりの改善。不自然さはなくなっていて、依存関係的に正しい感じになっていると感じました。Yii1は、アクションのアクセス制限の仕組みの根本は付け替え可能なフィルタ機能なのに、なぜかコントローラの抽象にaccessRulesなんてメソッドが最初からある、なんていう、現実的だけどちょっと変な進化をしてきた痕跡がありましたが、そこらへんたぶんだいぶ整理されてます。

ビューも、ビューファイルでいう $this が実はコントローラのことだった、なんてことはなく、yii\web\Viewインスタンスになっています。これまで可能だった、ビューヘルパーとしてコントローラにメソッドを追加、なんていう変な作り方はできなくなっています。

あと、これ大きいなと思うのが、エンティティとフォームを兼用しているあのARモデルですが、フォームっぽさがCRUD用途のみという感じになるように、Giiが生成するようになったことです。検索フォームなどDBの列とは別のプロパティが必要な種類のフォームは、エンティティのCRUDをやるためのモデルから外れて、検索だけやるフォームとしてARではない単独のフォームモデルに分離されるようになりました。

これ教育上とてもいいことだと思います。追加機能のためのフィールドをどんどんひとつのモデルに付け足して混在させていく作りって、モデル駆動の人にしてみたら、中心とするモデル実装の汚染なんですよね。でもプログラマーは、お手本コードに search() なんていう特殊なものを同じところに書いてあるなら、それ真似するでしょ。結果、どんどんひとつのモデルにフィールドとメソッドが増え、太っていきます。ファットモデル。Yii2の初期コードは、それをしないお手本になっている気がしました。(それでいてフォームバリデーションを最低限必要なぶんだけ同じ所に持っているモデルというのは、素早いプロトタイピングをやるのにすごく便利です)

Yii経験者じゃないと何のことかわからないと思いますが、とにかくYii2はよくできています。速さと便利さのためにいくらか犠牲になっていた、正しい方法への誘導というフレームワークの意義を、可能な限り取り戻そうという意図が感じられました。数年後、PHP界の正しいRailsとして選択の余地なしという評価をもらえるものになっていると思います。たぶんね。

PHPでは配列ではなくオブジェクトに状態を持たせよ

アドベントカレンダーを書いたらコメントに面白い課題もらいました。

Python - すごく簡単なアルゴリズムがphpで書けなくてつらい」のやつ。

id:methane

php の array と参照の関係がクソで無いなら、 http://qiita.com/methane/items/41e1376c41d8c15e8894 これを普通に書いてみてください。

id:tanakahisateru

面白そう。やりましょう。

最近ずいぶんPHP成分多めですが、実はPythonも好物なのでホクホクです。

といっても、あのエントリーは「php の array と参照の関係がクソで無い」とは言ってなくて、むしろ逆にそこは腐ってるから避けろ、オブジェクトで囲んでやれ、という話だったので...(^^ そのままやってもPythonの性能にはならないとわかっているので、配列を直接使うのはイヤです。なので、オブジェクトが状態を持つように書けという主張がどういうことなのか、実装で表してみたいと思います。

あ、5.5 の yield 使ってます。せっかく PHP にも Python のあれができたので。 yield なんてズルいと思う人はそういうイテレータークラスを実装したらいいと思います。イテレーターの実装が面倒な人は Ginq とか検討してもいいかもです。

<?php
/**
 * 末尾から消化できるシーケンス
 */
class TailConsumableSequence
{
    protected $sequence;

    function __construct($source)
    {
        $this->sequence = $source;
    }

    /**
     * Pythonのpopと同じようなもの
     * 末尾からゆらぎぶんさかのぼって抜き出す
     */
    function consume($fluctuation=0)
    {
        $size = count($this->sequence);
        $targetPos = $size - 1 - $fluctuation;
        $consumedValue = $this->sequence[$targetPos];
        for ($i = $targetPos; $i < $size - 1; ++$i) {
            $this->sequence[$i] = $this->sequence[$i + 1];
        }
        array_pop($this->sequence);
        return $consumedValue;
    }

    /**
     * n以上残っているか
     */
    function remainsEqualsOrMoreThan($n)
    {
        return count($this->sequence) >= $n;
    }

    /**
     * 残り数かlimitかどちらか小さい方
     */
    function sizeOr($limit)
    {
        $size = count($this->sequence);
        return min($limit, $size);
    }
}

/**
 * 数列の後ろのほうからごにょごにょ拾ってきてペアを作る
 * ごにょごにょ = 最末尾とそこから limit までの範囲さかのぼった位置のペア
 */
function allRandomPeairsFrom($sequence, $limit=100)
{
    $tcs = new TailConsumableSequence($sequence);
    while ($tcs->remainsEqualsOrMoreThan(2)) {
        $a = $tcs->consume(); // 最末尾から取る
        $b = $tcs->consume(
            mt_rand(0, $tcs->sizeOr($limit) - 1)
        ); // 最末尾からある程度さかのぼって取る
        yield [$a, $b];
    }
}

function test($n, $r) {
    foreach (allRandomPeairsFrom(range(0, $n-1), $r) as list($a, $b)) {
        //printf("%d %d\n", $a, $b);
        assert($a - $b < $r * 2);
    }
}

test($argv[1], 10);

これでいかがでしょうか。追記3のベタ書きと同じような特性なのに、わりと読めるコードでもあります。

$ time php matching2.php 10000; time php matching2.php 20000
php matching2.php 10000  0.23s user 0.01s system 99% cpu 0.245 total
php matching2.php 20000  0.40s user 0.02s system 98% cpu 0.421 total

追記2 で list_pop() にしていた処理をベタ書きしたら、やっと予想通りの性能が出るようになった。 php で配列の参照に対して操作してはいけない。つまり、配列を操作するアルゴリズムを関数にしてはいけない。

すごく同意。関数にしてはいけない。配列の参照に対して操作してはいけない。生で配列をごりごり書き換えるとポインタが使えないためにリファクタできなくなってハマる。じゃあどうするか...

PHPで状態を持つバッファは、オブジェクトで囲むといいです。参照渡しとか配列のコピーとかから来るややこしさから解放され、ベタ書きしたのと同じような動きになります。オブジェクトはポインタなので、好きなだけ関数に渡してもよくて、もっといいのは、オブジェクトのフィールドはスコープを行き来するローカル変数より、もっと安定したメモリに置いてあるってことです。

あの「状態の変化は、それを意図したメソッドを持つオブジェクトでのみ起こるべきです。」というのは、お作法の話であるという側面もあるけど、他に、そう書いたほうが参照渡しよりも問題が簡単になって、がんばらなくてもパフォーマンスが安定する、という意味でもあるんです。

まわりくどくて重厚に見える方法のほうが実は素直、というのが最近のPHPの面白いところです。OOPのお作法がよくなるのと、物理的に悪いものから遠ざかるのが反比例じゃない感じ。

PHPのarrayはPythonでいうところの名前付きタプルとして使うぐらいが、いちばんいい使い方だと思っています。

PHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪い

この投稿はPHP Advent Calendar 2013の12日目の記事です。

PHP恒例行事の参照と三項演算子のdisりですが、そろそろあさってな議論はやめませんかという話です。

今年のPHP-dis大賞といえばこちら。

PHPとかいう糞言語|いんまのブログ

※ 追記: これ書かれたのは2012年でしたすんません。

なんで君たちそんなコードが必要なのかね、と。結論から先言うと、きみたちがPHPが使えないって思うのは、そんな挙動に左右されるようなコードを書くからでしょ、だからCとかRubyとかそういう簡単な言語でわかった気になっている初心者はまったくもう...というわけでPHPの言語文法の基礎んとこ、いきますね。

まず、PHPのarrayは「値」です。もちろん文字列も「値」です。値は値なんだけど、それはミュータブルです。PHPのarrayもしくは文字列の代入は、一見すると、ポインタを使わない大きなC構造体を代入するような感じになります。

function x2first($arr)
{
    $arr[0] *= 2;
    return $arr;
}

$input = array(1, 2, 3, 4, 5);
$output = x2first($input);

// PHPの配列渡しはポインタではない
assert($input[0] != $output[0]);

PHPでは、コール先で中身を変更しても、コール元のスコープでは変数の値が維持されています。

で、ここでポインタわかって調子乗っちゃってるプログラマーは誤解するのですよ。大きな配列や文字列を別の変数に代入したり、関数に渡したりすると、その回数ぶん メモリの確保とバイナリのコピーが起こっている と。

その勘違いに捕らわれた人は、C++の参照演算子(ポインタを逆に表現した感じのアレ)を思い出して、「そうだPHPでも参照を使えばポインタと同じだ」と思い込んで、まあこんなコードを試すわけです。

function x2first_ref(&$arr)
{
    $arr[0] *= 2;
}

$input = array(1, 2, 3, 4, 5);
x2first_ref($input);
// 引数がコピーだということは、ポインタ相当のパフォーマンスを得るには参照渡しかな
assert($input[0] == 2);

やったーこれでメモリのコピー量がスタックに8バイト積むだけで済むぜ。

んなわけねーよ。

まあ、それほど極端でなかったとしても、みなさん計測せずに感情的な判断をしていませんか? パフォーマンスのために書いたつもりが、計測してないなんて、そんなの一度も実行してないのにバグってないロジックができたと言い張ってるようなものですよ。

ちゃんと計測します。

function profile($funcname)
{
    $bigarray = range(1, 1000000);

    echo $funcname . "\n";

    if ($funcname) {
        $start = microtime(true);
        $ret = $funcname($bigarray, 500000);
        $end = microtime(true);
    } else {
        $start = microtime(true);
        $end = microtime(true);
    }

    echo "  caller memory: " . number_format(memory_get_usage()) . "\n";
    echo "  time: " . (($end - $start) * 1000) . "(ms)\n";
    unset($bigarray);
    unset($ret);
}

ob_start();
profile(null); // ウォームアップ
ob_end_clean();

誰でも試せる素朴な計測ツールです。zval_とかわからなくても大丈夫な感じのやつ。100万要素の配列を準備して、処理にかかった時間と、呼び出し元スコープでの使用メモリを報告します。

まずは、本当に何もしない場合の数値を基準として取っておきましょうか。

profile(null); // 関数を呼ばない場合

// caller memory: 144,639,024
// time: 0.0030994415283203(ms)

実行するときは、たぶん php.ini のメモリ上限にひっかかるので、上限外してやりましょう。

$ php -d memory_limit=-1 test.php

さてじゃあ、引数渡しと戻り値の返却を、参照ありなしいろいろ試してみましょう。

// 参照なし
function nop_noref($arr)
{
    echo "  callee memory: " . number_format(memory_get_usage()) . "\n";
    return $arr;
}

// 参照渡しのみ
function nop_ref_arg(&$arr)
{
    echo "  callee memory: " . number_format(memory_get_usage()) . "\n";
    return $arr;
}

// 参照渡し+参照返し
function &nop_ref_both(&$arr)
{
    echo "  callee memory: " . number_format(memory_get_usage()) . "\n";
    return $arr;
}

profile('nop_noref');
profile('nop_ref_arg');
profile('nop_ref_both');

// nop_noref
//   callee memory: 144,639,072
//   caller memory: 144,639,072
//   time: 0.028133392333984(ms)

// nop_ref_arg
//   callee memory: 144,639,128
//   caller memory: 241,027,888 ← コール後にメモリ増大  
//   time: 106.05406761169(ms) ← なんだこれは

// nop_ref_both
//   callee memory: 144,639,112
//   caller memory: 144,639,112
//   time: 0.034093856811523(ms)

おい参照渡し、参照しない場合に対して処理時間が3700倍とかどないなっとんじゃい。

参照渡しのみした場合、見事にメモリが倍になっています。つまり巨大配列のコピーが発生した証拠です。実はこれ、参照返しをしなければ、戻り値の受け取りのとき、配列のコピーが生まれているのです。参照渡しだけでなく参照返しも意識しないと、こんなふうに内容が同じ100万要素の配列が2つできちゃう。こいつは厄介...

いや、厄介じゃないですね。驚くべきことに、いっさい参照を意識していないコールが最も優秀になっていますね。安全だし速いし。パフォーマンスのために内容破壊のリスクを冒して参照渡しするべき、とか考えてた人は残念でした。その努力には、まったく意味がありません。

いちど構造が作られてしまったら、多くの場合は読み取りアクセスだけで事足ります。読み取りに関しては、参照渡しだろうとそうでなかろうと、その負荷はまったく同じです。(7マイクロ秒の差は計測誤差です)

function getat_noref($arr, $index)
{
    echo "  callee memory: " . number_format(memory_get_usage()) . "\n";
    return $arr[$index];
}

function getat_ref(&$arr, $index)
{
    echo "  callee memory: " . number_format(memory_get_usage()) . "\n";
    return $arr[$index];
}

profile('getat_noref');
profile('getat_ref');

// getat_noref
//   callee memory: 144,639,168
//   caller memory: 144,639,168
//   time: 0.03814697265625(ms)

// getat_ref
//   callee memory: 144,639,232
//   caller memory: 144,639,232
//   time: 0.030994415283203(ms)

参照にパフォーマンス上の意味はない、つまり、参照記号の & は、コール元に魔の手を延ばして値を書き換えてやるぞ〜、と待ち構えている怖いヤツの目印だというだけなんですよ。

もういちどポインタを思い出して。そう、PHPの変数は、最初からすべてポインタなのです。だから特別な記号を使わなくても、いくらでも変数を関数に引き渡せるのです。いやそうとしか説明できないでしょ、この結果見たら。

PHPで、すごく層の厚いフレームワークが案外実用的な速度で動く理由は、実はこのへんが効いているんですね。リクエストごとにやり直しでありながらも、言語ランタイムで代入が自動的にすべてポインタなので、層の間で無駄なコピーが発生していない。だからこそ、大きなarrayをコンフィグとして取り回したり、設計をあれだけ高級化しても案外ダメージが少ない。

でもまって、中で変更しても外は保護されてたアレはどう考えてもコピーでしょ。----そうですね、アレを試さなきゃ。

function x2at_noref($arr, $index)
{
    echo "  callee memory1: " . number_format(memory_get_usage()) . "\n";
    $arr[$index] *= 2;
    echo "  callee memory2: " . number_format(memory_get_usage()) . "\n";
    return $arr;
}

function &x2at_ref(&$arr, $index)
{
    echo "  callee memory1: " . number_format(memory_get_usage()) . "\n";
    $arr[$index] *= 2;
    echo "  callee memory2: " . number_format(memory_get_usage()) . "\n";
    return $arr;
}

profile('x2at_noref');
profile('x2at_ref');

// x2at_noref
//   callee memory1: 144,639,360
//   callee memory2: 241,028,168 ← ここでメモリを大幅に確保
//   caller memory: 241,028,168
//   time: 111.29093170166(ms) ← コピーコスト

// x2at_ref
//   callee memory1: 144,639,376
//   callee memory2: 144,639,376
//   caller memory: 144,639,376
//   time: 0.036954879760742(ms)

最初の nop_noref() に対して、この x2at_noref() がちょうど、中身を操作するかしないかの違いになっています。中身を操作しなければポインタのままだったものが、操作したことによって実体を共有できなくなると、こんどは裏で勝手にクローンが作られる、これがPHPの「普通の変数」の正体です。なんという高級言語。わざわざそういう最適化を書かなくても、言語ランタイムが暗黙的にやってくれてるんですよ。

こう見ると、参照のほうがむしろ普通に見えてきます。ただまあ、PHPの参照はいちど変数が参照になってしまうと、二度ともとに戻ることができないので、扱いにくくてやっぱりダメです。我々アプリケーションプログラマーにとっては、より平易で少ないコード量で、より安全で最適化された処理を得るのが正義なんですから。

zval の is_ref がどうとかあたりのちゃんとした説明は、2013-03-07 - bravewood の日記 で読めます。中身にこだわる方はどうぞ。参照代入演算子は、右辺の変数の特性をこっそり変化させてるあたりで、「うわなにこれ演算子の見た目に騙されてた」感を堪能できますよ。

まあ、そもそも話で、LLな言語の変数がミュータブルなのはしょうがないですが、であるからこそ、別のスコープではできるだけイミュータブルな値であるように意識して扱うのが、うまいプログラムのお作法ですよね。どこで中身が書き換えられるかわからない、副作用を期待した作りではなく、生成は生成に関わる箇所だけで、読み取りは参照透過で途中で言ってること変わらない、となっているのが、言語を問わず良いとされる方法です。

状態の変化は、それを意図したメソッドを持つオブジェクトでのみ起こるべきです。コードの中にできるだけ状態を作らない。わかりやすいインターフェースのオブジェクト設計で、これは状態だ、他は状態じゃないと静的に判別できるように考えましょう。今のPHPのオブジェクトインスタンスは、Javaのそれと同じく、明示的なクローンをするまで実体はひとつです。arrayを直接ではなく、可変な変数を持つオブジェクトを用意して、オブジェクトを普通に関数に渡し(オブジェクトは素直にポインタです)、そのオブジェクトのメソッドを使って変化を管理しましょう。

というわけで、参照渡しをカジュアルにやるのが間違いなのです。関数の戻り値の型の整合性がとれず、やむなく出力引数で表さなければならない場合などを除いて、基本的には使わない。使う意味がない。参照の仕様から来る複雑さに関しては、PHPが悪いというより、基礎を押さえずに用途を勘違いして使うほうが悪いと思います。PHPの変数の基礎を知っていれば、ほとんどの場合使わなくていいということが、おのずとわかると思います。

PHPが変な言語に見えるのは、そういう特殊な高級言語だと知らずに、素朴なメモリモデルを持つCのようなもので例えようとするのが良くないのです。もちろん、本当のビギナーが誤解して使っている場合も多いですが、よりややこしいのは、少々わかったふうな若葉マーク取れたぐらいの人が起こす勘違いです。そこに門外漢が弱いものいじめのように集まってきてしまう。本当のPHPプログラマーは、これがどういう言語なのかをよく知って、つつましく適切に、でも都合のいいところを活かして便利に使うのです。

まったく役に立たないかに見える参照の機能ですが、僕は、ここだけは使えるというホットスポットがあると思ってて、あとはそれを紹介しておきますね。

$str = '123-456';
preg_match('/^(.*?)-(.*?)/', $str, $match);

preg_match()の第三引数は参照渡しです。このコールで、$matchは宣言されている必要がありません。このように、コール元のスコープの変数の代入式と同じように働く参照渡しは、時として役に立ちます。

あと、クロージャが束縛する変数。

$removed = array();
$data = array_filter($data, function($element) use(&$removed) {
    if ($element->ckeck()) {
        return true;
    } else {
        $removed[] = $element;
        return false;
    }
});

$removed の参照を束縛しています。ここがもし参照でなかったら、まさに引数に配列を渡したときのように、クローンに対して操作され、$removed=array(); が維持されてしまいます。本来はオブジェクトを設けるべきなのかもしれませんが、クロージャがインラインで複雑さをさっと閉じ込めてくれることを思うと、こういう場合は、素朴なforeachループルーチンと置換えられるような手軽さが合っています。

個人的には、参照がありがたいと思って使うのはこれぐらいです。他に使い道ってあまりないなぁ。

あ、そうそう、参照を使ったら、忘れずに unset() するか、すぐにそのスコープを抜けること。変数がいちど参照になると、同じ名前でその変数名を再利用することができないのです。以後そこに代入するのは、参照先の領域への書き込みという意味になってしまい、新たな値を持つ変数を作るという意味にはなりません。

えーと、PHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いって言ってごめんなさいなので、歌って気分を晴らしてください

"仕様が理解らないの〜 なぜだどうしてだ〜 アホかー"

参考: http://www.youtube.com/watch?v=fZ-CM7n3F5c

明日は @ockeghem こと徳丸先生です。楽しみですね。

書籍感想: PHP逆引きレシピ 第2版

出版社から頂いたので読ませて頂きました。ありがとうございます。

PHP逆引きレシピ 第2版

PHP逆引きレシピ 第2版 (PROGRAMMER’S RECiPE)

2800円なんですが、この価格に対して内容量おかしいぐらい豊富です。

体裁としては、まだ経験値が少ない初心者向けという雰囲気ですが、実際の動作に影響する点については、驚くほど正確な自己ツッコミが入っていて、実はすごい知識に支えられているんだというのがわかります。重箱の隅をつつけばつつくほど、勉強になる本だと感じました。

おそらく初版で意識していたPHP4〜5.2への配慮を、きっちりと、今の世代では切り捨てるべきものは今のやり方に置き換えてあるのは、素晴らしいです。これだけの書き換えをやって、全ての内容を検証してあるんだとしたら、本当に頭が下がります。

加筆された部分は、セキュリティ対策に関する解説が期待をはるかに上回っていました。PHP4から5の初期の時代に初版が出版された本であるという歴史を引きずっているため、たとえばURLパラメータにセッションIDを付けた場合や、あの magic_quote_gpc にも言及していながら、それでいて、ちゃんと理屈をふまえたセキュリティリスクの総まとめになっていました。

他のセクションが一話完結なのに対して、セキュリティについては、まず理解するうえで絶対外せない説明があって、それから。php.ini の網羅まで進む。頭から通しで読んで内容が一貫しているという異例の構成となっています。たぶんそこだけで十分に買う価値があると思います。

一話完結なのでもったいないと思ったのは、自動テストでした。たぶん、前提としてオブジェクト指向設計を習得できているというのが必要なのに、対象読者を「クラスとかよくわかんない」な層と想定していて、単体テストがクラスに対応するところから始められない、といったジレンマはあったんだろうなあとは思いますが... であれば、セキュリティの章のように、PHPにおけるOOPも一貫して、ってできていたらよかっただろうな。そうしたら、PSR-0 からの Composer についてももっと馴染めたろうに、とは感じました。

とはいっても「目で見て確認します」「zipを展開します」ではなく、自動テストや自動的な依存解決へのアンテナを貼るのを、「var_dumpってなんですか」「XAMPPをインストールしましょう」という見出しを持った本で展開できるというのは、素晴らしいことです。ああ、それだけに、OO設計とフレームワーク概念が不足気味なのが本当に...

ごめんなさい、不満ついでにこれだけは、という点を3点ほど。

ひとつは、すべてのサンプルコードがWebサーバで動かすように書いてあること。ちゃんとコマンドラインで実行することも書いてあるし、PHPUnit も Composer もコマンドラインでしか動かないものを扱っているんだから、HTTPとは本質的な関係を持たないコードは、PHPインタプリタに食わせるスクリプトであっても良かったはずです。Webページでなければならないせいで、コードが冗長になってしまって読むべき場所がぼやけ、出力結果サンプルとの照合時に距離ができちゃってるんじゃないかなと思いました。

もうひとつはこれ:

require_once '../../hoge/fuga.php';

PHPプログラミングするひとは、お願いですから、__DIR__ をつけてください。初心者PHPer(あるいは初心者から成長していないプレーンPHPおじさん)には、なるべく早く、相対パス指定の癖を抜いて欲しいのです。カレントディレクトリは chdir() で移動できます。自分のスクリプトではやっていなくても、require 先で起こっていてるかもしれません。カレントディレクトリは暗黙で扱いにくいグローバル変数なのです。

PHPをHTMLの埋め込みマクロとして使う、本当に簡易な使い方をする場合、「includeで別のディレクトリから共通ブロックを読み込み」とかやりますね。その場合、読み込まれた側(ヘッダなど)でライブラリ(ログインセッションの確認など)を相対パス require_once すると、「誰が自分を読み込んでいるかによって基準ディレクトリが変わる」ことになってしまい、これって「あらかじめ使う人を知っている部品」になってしまいます。

過去と未来、すべての __DIR__ なし require_once を生まれる前に消し去りたい。

require_once __DIR__ . '/../../hoge/fuga.php';
// もしくは require_once dirname(__FILE__) . '/../../hoge/fuga.php';

最後の不満は、ズバリ、PhpDocがないことです。紙面上でせっかくNetBeansをオススメしているのに、コードに型情報を書いてないと、IDEのパワーが半減しちゃいますよ。紙面上docコメント書くと狭いのはわかるんですが...

うーん、まあ、僕の不満点も、「どこからでも読める本」とするために、できるかぎり他のトピックの知識を必要としないように、という配慮の結果なんだろうけど。うーん。「まずは絶対にこれだけ押さえておかないと、この本は読めません」っていう導入があれば... いやそれだと買っただけで明日から使える逆引きとしては... もやもや。

だめですね、良し悪しじゃないですね。個人的にどうかというと、確実に「予想外にも読んでおいて良かった本」でした。それは大丈夫。2800円はお買い得です。不満なところは3つだけで、あとはもう、圧倒的なボリューム感でおなかいっぱいです。

たぶん、自分のもやもやは、かつてPHPerと呼ばれた層と、いま必要とされている技術に、外からは理解されていないギャップがあるのではないか、という点に行くのかなと思います。昔からやっていて、時代とともに成長している人はいいんだけど、これからやる人も、昔のまんまの人もいる、他の言語やっててPHP4以来のご無沙汰だから逆引き本を買っておこうという人もいる、その中心で全方位からの攻撃に備えよ、となると、やっぱり、PHP逆引きレシピの構成と厚みになるのかなーと思ったりしています。

むずかしいですね。でもまあ、そんなこと言ったらRubyの技術なんて明らかに紙が追いついてない感じだし、PHPもそろそろ「初心者にも簡単な言語」という解釈ではない、本当は難しいWebアプリケーション、という、いっちょまえのステータスをもっと評価される時代なのかもですね。

就職しました

退職エントリーがあるなら就職エントリーがあってもいいじゃないか。

というわけで10月からクックビズ株式会社に就職しました。

就職といっても、フルコミットより何割かゆるいコミットメントで、現在個人で扱っている案件をすべて切る必要はないという条件で、まずは半年単位の契約でやらせてもらうことになりました。長期的に確保されちゃうことはできないですが、機動力は衰えておりませんので皆様よろしくお願い致しますですよ。

クックビズは、飲食業界を専門とした人材サービスを行っている会社です。ITサービス/ソフトウェア開発そのものの会社ではないので、人の割合でいうと技術の人の割合は少なめです。

なんでまたそこに。

阪急梅田駅と御堂筋線梅田駅のすぐ近く。もちろんJR大阪駅も。ということは...グランフロントもヨドバシも眼と鼻の先です。阪急の高架を抜ければ茶屋町側に出るのもすぐなので、中津の某 1x1 勉強会にも歩いて行けます。ロケーションがいいですね。

で、この場所、事業内容のせいでそうそう移転する心配がないのです。というのも、コンサルタントがサービス利用者を呼んで面談をする必要があるので、カバー地域の中心に位置してることがマストなのです。

グランフロントのナレッジサロン使ってる人は来るとき教えてください。ゲストのふりしてランチにいきます。デザイナー職、エンジニア職の方は、ナレッジサロンから弊社見学に来てくださってもよろしくてよ。

ってだけで就職というとカッコ悪いので、言い訳も足しておきます。

ITの業界って、営業職/企画職といえば開発職の敵みたいなところがありますよね。クリエイティブ方面でも、代理店なりプロデューサーなりと実際のクリエイターの関係といえば、...ねぇ。彼ら営業職は、納品の瞬間がゴールなんですね。売る人たちって、平常運転に入ったらそのあとは、いかに動かないかが勝負、みないなモードになっちゃいます。

そういうビジネスのフローにいると、新規開発が終わった瞬間が一番儲かる、というのが当然みたいになっちゃって、いかに新規を継続的にリリースするかという仕事のやりかたになります。そうでないと赤になる、という考え方が当たり前だと思っちゃう世界(たぶんそれは錯覚)。難しいのは、これ、個人に近くなればなるほど、その傾向が強くなるんですよね。腕の立つ火消し連れて来い、予算は作業の実費ぶんだけある、って具合。

珍しく平常運転にバリュー(保守費ってだけじゃなくて顧客に対する企業価値も)が得られるって考え方の組織があっても、それは組織のもの、みたいなケースがほとんど。まあ、個人の価値を認めてくれるありがたいお客さんはいるので感謝はしてるんですが、そのお客さん自体が納品の対価で商売している以上、新しい技術課題のクリア以外に支払えるものとなると、やっぱりないんですよね。

そもそも売上が安定するはずがない業界ってのははじめから承知。なんだけど、そういう状況にいるとやっぱり気になるのは、システムやデザインの本当の価値ってのが、使い続けるところにある、変化し続けられるモデルを維持するっていう、核心のところなんですよ。

毎日安定して動くか、ユーザのモチベーションが下がらないか、なんかに関心を払うより、納品の瞬間が最高にピカピカしていて満足感が高いものを持ってきて売ってしまうほうが効率いい、みたいな商売の価値観に、少なからず影響される仕事しかしていなかった。なので、ユーザ会社の中に入ってしまうことで、逆に、そういう価値観の外で働く感覚を得るチャンスにできないかと思ったわけです。

ほんとぶっちゃけ、クックビズの営業職はIT製品をなにひとつ売っていないのですね。コンテンツもバナー領域もライセンスも何も売らない。扱っているものが人材と求人だけ。つまり対立ポイントがありえません。これがすごくいい。会社として営業力が高いというだけでも素晴らしいのに、しかもそれが衝突する相手でなく直交関係なんですよ。ここでは、社内の人が営業SEなんじゃなくて、リアルなエンドユーザーです。(普通ここ、自社の営業SEと相手会社の担当SEが挟まりますよね。) もしかしたら、自分でさえ、一部の機能に関してはユーザになりえます。

ちょっとITを直接商売にする場合に思いを馳せると、「リリース時のアウトプット100%の犠牲として保守性を犠牲に」という考え方、これ悪いことみたいだけど、請負であれば程度問題で正義でもあるんですよね。釈明が要らないモノは、担当営業SEの人的コストを下げるので。で、自分が入社する前の現行システム、まだ社内にWeb技術のセクションがなかった頃のコードが、まさにそんな感じでした。すごく頑張って機能を作っているのに、その見た目からは乖離した内部設計っていうアレです。

ああ、もし作る人が「保守開発と付き合う時間のほうが長い」という立場で作り始めていたら...

というわけで、社員として、迷いなく保守性のほうを選べるポジションで、毎日一定のペースで改善していけるソフトウェアが作れるチームを目指して、しばらくやってみようと思います。

cook+bizcoはPinocoとは無関係ですが、かわいいのでお友達になりたいです。すでにPinocoのコードはcookbiz.jpサイトの主な機能に使われています。やっぱ便利やで。