Software Designの2015年1月号「ソフトウェア開発の未来」

久々に本屋でIT関連の雑誌を買った。
ランチの後に、近くの本屋に入って手にとって見たのが、

Software Designの2015年1月号

タイトルは「Vim使い事始め」だけど、目に止まったのは「ソフトウェア開発の未来」のほう。特にサブタイトル「請負・受託開発は変わるべきか？」が決定的だった。

内容は、渋い。
目新しいことや、びっくりするようなことは書いてない。
知ってた、みたいな話も多い。

でも、こういう普通の話を聞く機会というのは少ないので、タメになる。

そして考えがスッキリした気がする。
モヤモヤと思ってたことを、整頓した感じ。

これからもSIという名前の請負案件はなくならない。日本のIT業界内でのシェアは減ってゆくと思う。が、絶対的な金額としては、特に中小規模は減らないのではないかと思う。

そして自分はお客さんと話をして要件を聞いたりまとめたりするのは好きだ。二次三次の下請けにならない限り、請負仕事は続けてゆくと思う。ただ直接お客さんと話せない状態になったらわからないかな。

今日のポイント。

設計力は大事。
シンプルな技術で長期間のサポート。
そしてお客様の困っていることを解決すること。

フレームワーク自作したい病が発生した

あまりに内容が薄いメモなので、自分のブログで書くことに。下書きみたいなものかと思われる。

StackPHPを参考にフレームワーク自作を始めた。自作すると大変、と言うのは経験済みだが、自作したくなってしまったのは仕方がない。

さて、大事な方向性は。

1. StackPHPのように「ミドルウェアのスタック」でウェブアプリを構築する。ただし、StackPHPは使わずに自作することに（理由は後述）
2. できるだけミドルウェア側に処理を寄せること。
3. ミドルウェアはできるだけ疎結合であること。
4. 既存のライブラリを有効に利用すること。
5. ウェブサーバーのフロントに特化。DBなどのインフラ周りは含まない。
6. ひとまずDIコンテナは利用しない。

書いてみたら真っ当な内容で、特に目新しさが感じられない。でも、調べたところではStackPHPを使ったフルフルなフレームワークが見つからなかった。

StackPHPを使わなかった理由

StackPHPのミドルウェアとして次の３つを満たす必要がある。

1. SymfonyのHttpKernelInterfaceを実装すること。
2. コンストラクターの第一引数として次のミドルウェアを受け取ること。
3. （必要であれば）handleメソッドの中で、次のミドルウェアを呼び出して結果を返すこと。

疑問に感じたのは、ミドルウェアの中に、「実際の処理」と「次の処理を呼び出す」、という２つの責務を持っていること。多すぎるんじゃないか？！

例えば認証とかフィルターを考えてみる。

使い方としては、ミドルウェアとしてスタックの中に放り込んで、全アクセスで必ず認証をさせる。あるいは認証する条件（URLなど）をつける。そしてbeforeなど特別な場所から認証フィルターを掛けてみる。

などなど、いろんな使い方が想定できる。

つまり、次のミドルウェアを呼ばない使い方も多いようにみえる。そうなら、このミドルウェアは処理部分とスタックの部分を分離するほうがよくない？と思った。

で作ったのがStackableというクラス。これにHttpKernelInterfaceを実装した処理オブジェクトをpushしてあげると、次のスタックになる。スタックの考えが単純なので、コード自体は簡単だ。

DIコンテナは？

今後、PHPでもDIコンテナは重要な、いや使って当然な技術になってゆくと思う。が、今はいろんなコンテナが乱立しているし、標準もないし、使ってみると「遅いし」。

なので、ひとまずDIコンテナなしで作ってみることに。ただし依存性の注入は行うことにして、単純なfactory methodを使う方向で作ってます。

ミドルウェア作成してみた感想

実際にミドルウェアを作ってみると、意外と疎結合しないことがわかった。不便なままならいいけれど、やっぱり楽に開発したいと思うとマジックが必要になる。

例えばResponseを返すミドルウェアが複数存在する。一方、ここはフレームワークで統一したい（というか簡単にしたい）と思ったとする。結局、リスポンスオブジェクトを作るファクトリをアプリの中に持っておいて、必要に応じて取り出しては使う、みたいなコードがあちこちに散乱している。

データも共有することが多い。例えばリダイレクトしたら、ちょっとしたデータを一緒にセッションで送りたい。つまりリダイレクト部とセッションでデータを共有する必要がある。後CSRFトークンとかね。

こういう疎結合しながら共有するパターンといえばイベント（Event AggregatorやMediatorパターン）らしい。

しかしながらですよ、ミドルウェアは順番に実行するものですよね。勝手にpushするイベント系は、スタックとは相性が悪いのでは？。なので、「ひとまず」データやオブジェクトをアプリにpush/pullをするようにして、必要に応じて共有することにしてみた。もう少し他のFWの実装を調べてみる予定。

ライブラリについて

今、使っているライブラリ。意外と少なかった。

• symfony/http-foundation
  スタックの基本なので、絶対外せない。
• symfony/routing
  ルーティングに使う予定。もっと簡単なのを探してます。
• league/flysystem
  設定ファイルを管理するためのファイルシステム。これにUnionManagerというのをかぶせることで、環境（productionやlocal）による設定を処理させる予定。
• league/plates, aura/view
  生PHPベースのテンプレート。どちらを使うかは検討中。
• wscore/form
  自作のHTMLフォーム生成コンポーネント。遅延評価でFluentにフォームが書けます。

LaravelのEloquent ORMについてQiitaに書いてみた

最近LaravelフレームワークのEloquent ORMを触ってます。まだ始めたばかりですが、2つほどQiitaに気がついたことをまとめてみました。

Eloquentのモデル生成法比較：newとcreate

Eloquentでリレーションを作成する方法


やはりMarkdown記法でかけるのがいいな。
特にソースコードの記述が楽だ。githubのお陰です。

Bloggerでも使えるようになるといいのだけど。

PHPでファイルポインターからファイル名を取得する方法

ちょっと調べたらStackOverflowで見つけた方法。
日本語のページが少なかったので書いてみる。

関数内で、ファイルポインターだけ渡されたのにファイル名が知りたい場合が出てきました。

$fp = fopen( $filename, 'r' );
function get( $fp )
{
   $filename = ... // ここでファイル名が知りたい。
}

引数にファイル名を追加すればいいのですが、面倒だったのでちょっと調べたら、すぐに答えが見つかりました。stream_get_meta_dataという関数。さすがPHPです。関数ほぼ一発で取得できました。

$info = stream_get_meta_data($fp);
$filename = $info["uri"];

だそうです。

2014年の抱負は「勉強」

あまり「勉強」は好きな言葉ではないけど。
そして、もう書いたようなものだけど。

簡単に言えば、

昨年は頑張ってアウトプット（コード）したら、
知識不足を痛感したので、
今年はインプット（勉強）を頑張ろう、

という話です。

■

何を勉強するのか。

まずはOOPの基礎やDDDからかなぁ。

マーティン・ファウラーの、あの本は購入済みなので、それを読もう。

後は、Doctrine2やAuraPHPなど、他のフレームワークを勉強したい。ただ全部入りより、各コンポーネントが充実＆使いやすい、というコードを勉強したい。

■

ただ、嫌いなことを頑張るのは難しい。
ひとまず、無理をしない程度がよいはず。

今、一番無理をしているのは目かも。
最近、目が疲れて仕事が続かないことが増えた。

ツイッターで、面白そうなリンクやブログを読むのも良いけれど、なるだけモニターを見つめる時間を減らして、目の使い方を変えたい。ということで、できれば本を読んで勉強できればよいなと考えてます。