選定した技術が1年で死んだ話

今年の夏頃から、特にサービスとして出すわけではなく、社内で使っているシステムのリプレースを行う事になりました。主な目的はレガシーすぎる設計をある低度モダンにする事、そして他のシステムと連携出来るようにする事、です。

対象のシステム

見積書や請求書などを管理・発行している。機能はそれなりに多いがUI操作はFormベース、テーブルタグで諸情報を表示するシンプルな物。ノンフレームワークで1画面1PHPファイルな古き良き時代のコード。おそらく10年ぐらい?稼働している。当初はPHP 5.1、PostgreSQL 8.x系だったが、現在はPHP 5.6とPostgreSQL 9.6で稼働しています。

その他の社内システム

かつてはノンフレームワークだったり、太古のバージョンのCakePHPだったり、PHPが4系だったりしたが、概ねCodeIgniter 3系最新版 + PHP 5.6~7.1 + PostgreSQL 9.6 / MySQL 5.6 に統一されている(統一する改修を進めてきた)。

対象のシステムをどうするか

これまで通りCodeIgniterでもよかったのですが、そろそろ新しい物を触ってみようかという事で以下のようなことを検討しました。

  • バージョン4以降の Laravel など、Symfonyコンポーネントを活用するフレームワーク、話題が流行っているように見える。PHPカンファレンスなどでも耳にする事が多い。
  • 軽量、軽快なCodeIgniterですら現状フルに機能を活用している訳ではない。URLのルーティング、エラーハンドリング、ログ出力、設定ファイル読み込み、Twigテンプレートエンジンの呼び出し、ORマッパーまでは使わない程度のDB機能、セッション制御、Composer対応が有れば十分に思えた。
  • Laravelは現行LTS期間が残り1年ほどと、すぐに次の更新を考えないといけないタイミングだった。
  • 都合上データベースの構造には大きく手を入れない方向。DBのカラム名が実装にかかわってくるタイプのフレームワークは使用しない。
  • Silexが使うDIコンテナ(もしくはサービスロケータ)の pimple はシンプルで分かりやすかった。
  • Symfonyコンポーネント製、必須機能だけを備え必要な物はSymfonyコンポーネントで追加するスタイル、数年間開発が続いている事、DIの仕組みが分かりやすい、DoctrineDBALでシンプルにDBアクセスが出来る Silex はそこそこ良いのでは。
  • Symfony自身が関わっているのでそれなりにしっかり開発されているように思えた。
  • あの EC-Cubeでもバージョン3で採用している。Web上で見かけた採用理由も近いものが有った。

実際の開発と設計

これまではほぼほぼ自分自身で開発してきましたが、このシステムに関しては社外の協力要員の方に実装して頂きました。私より実力が全然有る方なのでコード品質への懸念はあまりありませんでした。

設計はシステムを Controller, Service, Repository, Entity といったオブジェクトに分割した、ドメイン志向設計的な物になりました。Silexはマイクロフレームワークなので、それこそ1ページ1PHPファイルにしてしまう元とあまり変わらないような実装も出来てしまうのですが、だいぶモダンな設計になりました。これまでのシステムではほぼ不可能だったテストコードも書けるようになりました。

所感

先に述べたように、マイクロフレームワークである分、どうやって設計するかがかなり重要になってきます。設計力の有る方でしたので比較的綺麗な設計になりました。再利用性もそれなりに有るように思います。ただしもし設計がまずい場合、マイクロフレームワークである事がマイナスにしかなっていなかったかもしれません。

Silexがマイクロかどうかについては、普通に使う分には確かにマイクロなのですが、もともと高機能・フルスタックなSymfonyですので、機能を追加するたびにあれよあれよとComposer上の依存パッケージが増えていきます。困ったらコードを読める、かつ読みやすいのはやっぱりCodeIgniterの良い所でした。

突然の死

突然ではなかったのかもしれませんが、11月に Silex のサポート終了(EOL)が発表されました。2018年の6月にサポートが終了との事で、開発開始から1年で移行先の無いフレームワーク終了のお知らせとなってしまいました。

この技術選定はダメだったのか

Q. 素直にLaravelにするべきだったのか?
A. 今回はSymfony 4で互換性を切るという趣旨でのサポート終了であるらしく、Symfonyコンポーネントと関わりのあるLaravelについても、今までの事を考えても今後もそれなりに大きなアップデートを適用していく必要が有ります。もっとも、全く別のフレームワークを使うか、そのままでメンテをし続けていく必要が有る Silex より Laravel の方が未来が明るいです。

Q. マイクロフレームワークがいいならLaravelベースのLumenにすればよかったのでは
A. これは有るかもしれません。

Q. 同じマイクロフレームワークで middleware の仕組みが使える Slim は?
A. Slim は機能面で Silex 以上に薄い、との意見を見かけた事により実装しやすそうな Silex に流れましたが、Slim の方が未来が有った可能性は有ります。ただ、本当にこっちの方が未来が有ったかは今でも分かりません。

Q. 開発効率は良かったのか
A. これも何とも言えません。実装担当の方はLaravelもFuelPHPも経験者であったので、他のフレームワークでもそこまで大きな違いはなかったのではないかと思います。ただ、これは実装者の技術によるところでも有りますが、フレームワーク独自のしきたりをそこまで覚えなくていい、見通しのいい実装する事はできました。

Q. サポート期間が短い?
A. これまで数年に渡って開発されてきたので十分長くサポートされてきたと言えます。ただ、今このタイミングで採用したのは私の見る目が悪かった。もっとも、サービスとして外部に提供するわけでもないシステムなので、これまでがそうであったように使おうと思えば3年でも5年でも使えるでしょう(良くは無いです)。

Q. 目的は達成できたか?
A. クラスの無かったコードは比較的モダンな設計になり、テストコードが書けるようになり、今後ほかのシステムと連携させていく上でも拡張可能な物になりました。

結論

あまりこうだ、と言えることは無いです。長々と読んでもらって申し訳ないですが、どこがどう教訓とも何とも言えないです。Lumenの方が良かったかもしれませんが、結果論です。ひとまず、使える物は作れたので使っていく方向です。CodeIgniter安定!でもよかったのですが、CodeIgniterはドメイン志向設計な書き方にあまり向いていないように思うので、その辺りはコードレビューなどで勉強になりました。

そうですね、「フレームワークの寿命は選ぶ時点ではなかなか分からない」「寿命を気にするならベストだと思う物より、皆が使っているベターを選ぶべき」辺りでしょうか。以上です。


開発環境だけPostgreSQL + PHPの処理がめちゃくちゃ遅い理由がxdebugだった話

タイトルでもう内容が完結してしまっているのですが。アプリケーションにPHPを、DBにPostgreSQLを使っているシステムで、開発環境でだけやたら動きが遅い、具体的には5秒以上ページの表示に時間がかかるという現象を感じていました。特定の機能でだけ発生していました。

  • 言語: PHP 7.1.11 (Windows 64bit ThreadSafe版)
  • DB接続: DoctrineDBAL(pdo_pgsql)
  • DB: PostgreSQL 9.6.5

 

PHPやPostgreSQLのチューニング回り確認

PHPのメモリ設定は128MB、OPCacheも有効化済み、メモリ不足が出るような事も無く特に問題無し。PostgreSQLもshared_buffersは比較的大きなサイズが取られています。実行している処理もKabyLake世代のintel Core i7 + RAM16GB + 240GB SSDのマシンが悲鳴を上げるような処理とは思えません。

SQLの調査

特に重いページでPostgreSQLのクエリログ出力を有効化。

logging_collector = on
log_statement = 'all'

確認したクエリをPgAdmin 4からPostgreSQLに投げてみるも、1秒もかからず実行が完了します。となるとDB側は問題なさそうです。

コードの調査

PHPのコードを追いかけてみるも、特にネックになって居そうな処理はなく。

xdebugのプロファイリングが原因だった

そういえばComposerって「xdebugが有効だと遅いよ」というメッセージが出るよね、と思いだし
xdebug.profiler_enable=1 に設定していたのを
xdebug.profiler_enable=0 にしてみたところ、
あっさり解消。今まで5秒以上かかっていた画面が1秒未満で表示されるように。

本当の原因は何なのか

特定の機能だけやたら遅い状態だったので、PostgreSQL周りが常にxdebug要因で遅くなるというよりは、更に条件が有りそうです。同様に妙に(開発環境でだけ)重かった他のシステムではCodeIgniter 3のQueryBuilderとphp_pgsqlを使っており、DoctrineDBALやPDOが遅いという訳でもなさそうです。流石にxdebugのソースコードを読むのは辛いのでここから先は置いておきます。

開発環境のPostgreSQLがなぜだか遅いんだけど! という方はxdebugも確認してみるといいかもしれません。


Selenium IDEを失った僕たちはどこへ行くべきなのか (出題編)

それなりに歴史も有るSelenium IDE。Firefox上のプラグインとして動作し、Webブラウザを自動操作、グラフィカルだったりそこそこAjaxが入っているサイトでも操作やアサート条件が設定できるE2Eテストツールです。個人的にはWebアプリケーションのテストはコア部分以外は(単体テストよりも)E2Eテストで実操作に近いシナリオで動かした方が良いのではと思っている所も有り、そこそこ使っています。

しかし、そのSelenium IDEも実質終了してしまいました。Firefoxが旧来のプラグインに対応しなくなり、かろうじて旧プラグインが利用できているFirefox ESR(長期サポート)版も来年には次のバージョンが来てしまいます。

まだまだ使うぞSelenium IDE
https://qiita.com/hiroshitoda/items/f01cf25fd972f03c24ed

[2017年時点] Selenium IDE のまとめ
https://qiita.com/gluelan2013/items/daa8680e8e86c0937743

本家SleniumだったりWeb Driverだったりに行くべきなのか

Firefox ESR版が使える今であれば各種のプログラミング言語向けにエクスポートし、SleniumだったりWeb Driverだったりで動くものに乗り換えるべきかもしれません。Phantom JSとかKapybaraとかその辺も関係してくるのかもしれません。いかんせん実際に使った事が無いので、いちから調べる必要が有ります。今まで以上に自動化を進める(継続的インテグレーションへの組み込み)人向けのようにも感じ、GUIでぽちぽちするだけでテスト出来ていたソリューションを置き換える物としては「同じ事は出来るけど別の層向け」という印象が有ります。

SideeX(Web Extensions版のSelenium IDE)

URL: https://github.com/SeleniumHQ/selenium-ide

一応公式?なんでしょうか。Web Extensions版のSelenium IDEと言えるものです。ただ、頻繁に使っていたClickAndWaitが無かったりと、テストケースファイルの互換性に関しては何とも言えないものになっています。今後今までのシナリオと同等の物が作れるようになるんだろうか……?。実際に試してみたものの、全体的にベータ版感が有ります。

Katalon Recorder

URL: https://www.katalon.com/resources-center/blog/katalon-automation-recorder/

エクスポート機能も有り、仕様上はSideeXよりも高機能なエクステンションです。実際に試してみましたが、Chrome版だとページ内の文字列を取るバリデーションで動作が止まったり、Firefox版だと実行ボタンを押しても1ステップも動かずと、こちらも上手く動かず。UIはそれなりに完成度が高そうな感じなんですが……。ただ、他のツールとも連携するソリューションを目指しているようで、ツール開発の今後に期待が持てます。

正解がない

別物である事を受け入れたうえで、CUIやCI上のテストツールから実行するソリューションに行くのがおそらくもっとも無難。新しいものを知る事は勉強にもなる。ただ、SideeXやKatalon Recorderが今後便利に使えるようになるのかもしれない、という気持ちも捨てきれず。期待するなら開発に協力しろと言うのも有りますが(SideeXはOSS)そういった余力もなく。自分で作らずに無いものに対して「無い!」と駄々をこねるのも仕方が無いので、今後もFirefox ESRに残された期間で検討していきたいと思います。