雑なあらまし
- 友人との実験サイト作成で使うために、コア機能となる自作ライブラリをプロトタイピングしていた。
- 外部サービスアクセス用のいろんな認証キーを含んだままガシガシ書いていた。
- (実験だし〜軽くざっくり始めていけばいいっしょ〜) という程度の認識だった。
そのライブラリが大体出来たら、Laravelとかのフレームワークと一緒に使おうと思っていた。
が。
自作ライブラリを別作者の外部フレームワークから独立して改修 (保守) していくには、 require_once() (include ()) じゃ、すごい面倒が雪だるまじゃん！
課題 → ライブラリをアップデートした場合にフレームワーク内の同ライブラリどうするのか
- git のサブモジュール管理だと経験的に色々辛い (本番アップとかも)
- コピーしてrequire_once() だと似たようなものが複数箇所に分散してしまうことで、再利用性が下がる (他のプロジェクトでも流用しよう！となった時に、またコピーしてたら、どれが最新版か分からなくなって保守しきれない)
- シンボリックリンクでうんぬん→開発サーバーと本番サーバーが存在する時点で、どっちがオリジナルなのよ？どっちが最新なのよ？ってなっていっちゃう。ステージングとかテストサーバーも増えると、ほら、レガシーな感じで暖かみが出てくる。
やっぱり行き着くところは同じで、CPANやGemやpipとかそういうのに相当する composer がラクそうですよね…となった。
使うのはいいけど、自作するのは流儀を覚えるのが面倒で避けてた。(その辺のエンジニアあるある)
composerとは、php のパッケージ管理システムのアレ。 → Composer
composer.json に、メインシステムに必要な依存ライブラリを書いた後、
- php composer.phar install
とか
- php composer.phar update
とかするやつ。
参照したサイト
- Composer
- composer.json の書き方
- composer package を自作する場合にも書かなければいけない。
- Composer が PSR-4 に対応していた - ngの日記
- 名前空間とかディレクトリ構造、ディレクトリやクラスの命名について、 PSR-0 という 仕様要求→ガイドラインがあって、PSR-4 それの新しいバージョンらしい。 PSRが何の略かはコチラ
- 実例とコードを交えて解説してくださってる
- PHP Composer: Working with local repositories - henning glatter-götz
- ローカルリポジトリでゴニョゴニョするためは、という内容。
- こちらも実例を交えて解説してくださってる。
メモ
- .gitignore に
/vendorを入れておこう - PSR-4 の方が PSR-0 に比べて、ディレクトリ構造が冗長になりにくくて、よさ気
- 自作ライブラリを書いたら、そのディレクトリにおいて、git でコミットして、更にcomposer install/update もする感じ？ (gitでコミットだけでいいのかも)
- 本体は src/ に置き、テストは tests/ に置く決まり
- 通信が絡むテストは…勉強不足です。
- 1つのphpファイルに2-3のクラスを書いてたせいか、そのままだとサンプルプログラムにautoload.phpを取り込んで動かそうとしても動かなくて composer.json に classmap を指定して、再度、composer update したらサンプルプログラムが動いた。1ファイル1クラスの原則だったかどうかは、まだちゃんと各資料を見直してない
感想
- 土台になる部分を作るときは、あんまり雑に進めていくと後で帳尻合わせが増える
- 選定と検討にあまりに時間がかかっている場合、とりあえず手を動かして失敗をしていく方が「マシ」→悪いものと悪いものを比較した場合の話。
- いったん、composerパッケージにしてしまえば、composer対応のフレームワークなら他のフレームワークでも大体同じ感じで使えし、やっぱりgitのサブモジュールよりラク。
- パッケージ検索か依存性解決か、ちょいちょい composer install/update が遅い…(重い?)
新宿bookathon行って主催者さんからOSSコミッターとしてのお話を少し聞かせて頂いて、 ちょっと元気を貰ったので、家プログラミングが少し捗った。
