OpenPNE 3

• 一般に画像の変換処理は複数適用することが多いためフィルタとして実装される事が多いが，この実装ではそういったことは考慮されていないため複数の変換を行う必要があったり縮小アルゴリズム自体を入れ替えたりといった変更を行う際に実装コストが極端に高くなる可能性があります．この辺りの話は画像認識技術などで前処理と呼ばれる話が参考になると思います．容量を下げる目的は達成できているため今の時点では問題無いと思います．
• File クラスに File としての特性以外のメソッドを多く持つようになっています．出力時の画像のリサイズなどは sfImageHandler が担っていますが，この中でも実装がうまく分離できていないように見えるためあまり参考にはならないと思いまが，今後の課題として画像処理については別クラスや（広義における）別トランザクションとして分離するほうが望ましいのではないかと思います．

• （設計による問題として） https://redmine.openpne.jp/issues/3560#note-10 でも書きましたが同時に複数の実装を追加する際にそれぞれが独立した機能であるにもかかわらずマージが難しくなるような実装が容易に行えてしまいます．程度や優先度にもよりますが，マージ時の作業が行い易いように処理の塊はまるごと一つにして既存部分は数行追加削除のみといったような差分を心がけると喜ばれると思います．（もちろんこれは一般的な考えを述べているわけではありません）
• Doctrine では save() メソッドはいろんなところで暗黙的に使われている可能性があるため実装によっては意図しない呼び出しが発生する可能性があります．同じ save() の複数回呼び出しでもテキストについては非可逆な処理が行われていないため問題無いですが非可逆な圧縮を行う画像の場合 save() を呼び出すたびに画像劣化を起こす可能性があります．軽くながめた感じでは問題無いと思いますが注意する必要があるかもしれません．
• コミットメッセージが fixed となっています． wiki にも書かれていますが redmine のツールと連携をするために fixes のほうが正しいです．

メッセージは関連するチケットの ID を含んでください。 ID は 「refs」や「fixes」というキーワードを伴って指定してください。これを守るための有用なフックスクリプトを用意してあります: http://gist.github.com/202866

• 画像の容量を下げるアプローチとしてはピクセル数を下げるという方法の他に，圧縮アルゴリズムを変更するといったアプローチもあります．jpeg などはパラメータとして quality で画質を下げ，ピクセル数を下げずに保存時の容量を下げるようにしてといったことも可能かもしれません．容量を下げる目的は達成できているため今の時点では問題無いと思います．
• 例えば デジタル一眼などの高画質の画像をアップロードする際に極端に画像劣化を起こす可能性がありますがそのあたりの調整がしにくいようなパラメータのような気がします．サーバ側での画像縮小アルゴリズムやブラウザ側での画像拡大アルゴリズムなどによってその辺り変わるような気がするので，この実装でどのようになるのか挙動として把握しておく必要があるかなと思います．カスタマイズとしてこの辺りをよく変更する可能性が多分にあると思いますが，前述の設計で気になることで書いたように変更コストが高くなる可能性があります．容量を下げる目的は達成できているため今の時点では問題無いと思います．

更新履歴 bc4a264e875b6c27438fca8ba7236731a78fc08f で適用されました。