phpconJapan2023 わたし、Composerが気になります！

わたし、　　　　    2023/10/8    (株)インフィニットループ　  サーバーサイドエンジニア　 kerokero  が気になります

今回の発表の対象者  ・ Composerが気になる人   

今回の発表の対象者  ・ Composerが気になる人  ・ pharアーカイブってなんだよという人   

今回の発表の対象者  ・ Composerが気になる人  ・ pharアーカイブってなんだよという人  ・ autoloadってなんだよという人   

今回の発表の対象者  ・ Composerが気になる人  ・ pharアーカイブってなんだよという人  ・ autoloadってなんだよという人  ・ PHP初心者の人 ←
HOT‼  < ４つです 

Agenda  1.　軽い自己紹介    2.　Composerってなによ    3.　パッケージ管理ツールとしてのComposer    4.　pharについて    5.　オートロードについて 
  6.　反省点・良かった点・感想 

Agenda  1.　軽い自己紹介　　　　　　　　　　    2.　Composerってなによ    3.　パッケージ管理ツールとしてのComposer    4.　pharについて    5.　オートロードについて 

どうも、kerokero です。 

22卒　自称青魔道士系エンジニア   （株）インフィニットループ   kerokero ・北海道の札幌生まれ、札幌育ち  ・水産→数学(非情報系)→2022年4月にIL入社
　・最近の趣味は絵を描くこととストリートファイター6 です  ・担当領域はサーバーサイドのアプリ・インフラ実装(PHP, AWSなど) です  

とは？ 

ソースコードでなんでも生み出す。  最先端の最後尾を独走する 

Agenda  1.　軽い自己紹介　　　　　　　　　　    2.　Composerってなによ　　　　　　　    3.　パッケージ管理ツールとしてのComposer    4.　pharについて    5.　オートロードについて 

ある日のこと…… 

ある日のこと……  Composer って何なのですか？ 

ある日のこと……  Composer って何なのですか？  お願いです、kerokeroさん。  教えてください、気になるんです！  <  あいえるたそ 

<　(少し調べたのち……)　 

<　PHPのパッケージ依存管理ツールだよ！ 

>  パッケージってなんですか？  依存ってなんですか？   管理ツールってなんですか？  <　PHPのパッケージ依存管理ツールだよ！  あいえるたそ 

<　PHPのパッケージ依存管理ツールだよ！  パッケージってなんですか？  依存ってなんですか？   管理ツールってなんですか？  >  kerokeroさん。誤魔化さないでください。  気になります、気になります、気になるんです！あいえるたそ 

一度こうなるともう駄目だ。   

一度こうなるともう駄目だ。    疑問が解消し納得するまでしつこく繰り返し、絶対に諦めない。この一言をきっかけに物語が動くんだ。   

一度こうなるともう駄目だ。    疑問が解消し納得するまでしつこく繰り返し、絶対に諦めない。この一言をきっかけに物語が動くんだ。    その度に俺ことkerokeroは巻き込まれ、俺があいつを納得させるまで付き合わされる事になる。   

一度こうなるともう駄目だ。    疑問が解消し納得するまでしつこく繰り返し、絶対に諦めない。この一言をきっかけに物語が動くんだ。    その度に俺ことkerokeroは巻き込まれ、俺があいつを納得させるまで付き合わされる事になる。    つまり、俺の省エネ主義を粉砕する原因であり、俺にとっては聞きたくない言葉な訳だ。
ニコニコ大百科(仮) 「わたし、気になります」より一部改変 

一度こうなるともう駄目だ。    疑問が解消し納得するまでしつこく繰り返し、絶対に諦めない。この一言をきっかけに物語が動くんだ。    その度に俺ことkerokeroは巻き込まれ、俺があいつを納得させるまで付き合わされる事になる。    つまり、俺の省エネ主義を粉砕する原因であり、俺にとっては聞きたくない言葉な訳だ。
(やばい、うまく説明できない......)　← Now‼  ニコニコ大百科(仮) 「わたし、気になります」より一部改変 

というわけで、 

というわけで、  Composerについて整理してみました 

というわけで、  Composerについて整理してみました  (いよいよcomposerの説明に入ります)  

Agenda  1.　軽い自己紹介　　　　　　　　　　    2.　Composerってなによ　　　　　　　    3.　パッケージ管理ツールとしてのComposer　    4.　pharについて    5.　オートロードについて 

  気になります！  >  あいえるたそ 

  パッケージってなんですか？  依存ってなんですか？   管理ツールってなんですか？  >  あいえるたそ 

・パッケージって何ですか？  ・そもそも、PHPとは何なのか？ 

・パッケージって何ですか？  ・そもそも、PHPとは何なのか？    　　・オープンソースの汎用プログラミング言語 PHP    　　・公式の処理系である php-src 

・パッケージって何ですか？  ・そもそも、PHPとは何なのか？    　　・オープンソースの汎用プログラミング言語 PHP    　　・公式の処理系である php-src    ・これらは特に区別されることなく
PHP と呼ばれる 

・パッケージって何ですか？  ・公式の処理系である php-src に機能が詰まってると考えてよさそう    　　・変数や定数、関数、for文やif文など 

・パッケージって何ですか？  ・公式の処理系である php-src に機能が詰まってると考えてよさそう    　　・変数や定数、関数、for文やif文など      ・php-src
にない機能も使いたい    　　・ユニットテストや静的解析、便利なフレームワークなど 

・パッケージって何ですか？  ・公式の処理系である php-src に機能が詰まってると考えてよさそう    　　・変数や定数、関数、for文やif文など      ・php-src
にない機能も使いたい    　　・ユニットテストや静的解析、便利なフレームワークなど  ↑ これがパッケージということ

・パッケージって何ですか？  ≡  ・モジュールは関数、変数などのコードの基本単位    ・パッケージはモジュールの集合体    ・ライブラリはモジュール、パッケージの集合体 

・パッケージって何ですか？  ≡  ・モジュールは関数、変数などのコードの基本単位    ・パッケージはモジュールの集合体    ・ライブラリはモジュール、パッケージの集合体 
ライブラリ   パッケージ A  パッケージ B  モジュール  ← 大まかなイメージ ※言語や人によって流儀が違う可能性がある

・パッケージって何ですか？  ・なので、composer が管理しているパッケージというのは、広義の意味ではモジュール・パッケージ・ライブラリのどれかであると考えてよさそう      

・パッケージって何ですか？  ・なので、composer が管理しているパッケージというのは、広義の意味ではモジュール・パッケージ・ライブラリのどれかであると考えてよさそう     ・composer が管理している
パッケージは php-src の外部から仕入れてくるものと考えてよさそう    　　・phpunit や guzzle , Laravel など 

パッケージは php-src の外部から仕入れてくるものと考えてよさそう    　　・phpunit や guzzle , Laravel など    ・ざっくりとパッケージは外部からインストールするものと考えてよさそう     

パッケージは php-src の外部から仕入れてくるものと考えてよさそう    　　・phpunit や guzzle , Laravel など    ・ざっくりとパッケージは外部からインストールするものと考えてよさそう    　　　　　　↑ よっしゃー、とりあえず phpunit をインストールしてみるぜ　>   猫 

・パッケージって何ですか？  ・PHPUnit 

・パッケージって何ですか？  ・PHPUnit  PHPUnit に必要なすべての依存ファイルをひとつのファイルにまとめた PHP アーカイブ (PHAR)
を配布します      あるいは、Composer を使って PHPUnit やその依存ファイルをダウンロードしてインストールすることもできます。 

・パッケージって何ですか？  ・PHPUnit  PHPUnit に必要なすべての依存ファイルをひとつのファイルにまとめた PHP アーカイブ (PHAR)
を配布します      あるいは、Composer を使って PHPUnit やその依存ファイルをダウンロードしてインストールすることもできます。  依存ファイル

・依存って何ですか？  ・一旦、依存については置いておこう  これマジ？ >

・依存って何ですか？  ・一旦、依存については置いておこう    ・composer 自体の振る舞いをある程度知ってからの方が、ファイルの依存関係について理解しやすい        なるほど
　>

・依存って何ですか？  ・一旦、依存については置いておこう    ・composer 自体の振る舞いをある程度知ってからの方が、ファイルの依存関係について理解しやすい        わからん
　> ↑ composer 自体の振る舞いって何？ 

・依存って何ですか？  ・PHPUnit  PHPUnit に必要なすべての依存ファイルをひとつのファイルにまとめた PHP アーカイブ (PHAR)
を配布します      あるいは、Composer を使って PHPUnit やその依存ファイルをダウンロードしてインストールすることもできます。  ちょっとスライドを戻って……   ↑↑ こっちの話 

・依存って何ですか？  ・ひとまず前提知識として    　　・composer 自身も1つのパッケージであることは分かる    　　　　・php-src に含まれている機能ではないということ 
 

  　　・composer をインストールしてくる必要がある  　　　　  　　　　・とりあえずdockerコンテナでcomposer環境を試す 

  　　・composer をインストールしてくる必要がある  　　　　  　　　　・とりあえずdockerコンテナでcomposer環境を試す  頭の中に思い浮かべてみよう >

・依存って何ですか？  . ├ Dockerfile ├ docker-compose.yml └ composer.json # New!
・composer を実行できる環境を用意  tree 

・依存って何ですか？  ・composer を実行できる環境を用意  . ├ Dockerfile ├ docker-compose.yml └ composer.json
# New! { "require-dev": { "phpunit/phpunit": "*" } } ・phpunit について書かれている......？  tree  composer.json 

# New! { "require-dev": { "phpunit/phpunit": "*" } } ・phpunit について書かれている......？  tree  composer.json  ・この composer.json というものは、Composer がインストールしてくる対象を決定している「何らかの定義」が書かれているファイルとして存在しています 

# New! { "require-dev": { "phpunit/phpunit": "*" } } ・phpunit について書かれている......？  tree  composer.json  ・この composer.json というものは、Composer がインストールしてくる対象を決定している「何らかの定義」が書かれているファイルとして存在しています      ・ここに欲しいパッケージとそのバージョンを指定してあげるとよさそう 

# New! { "require-dev": { "phpunit/phpunit": "*" } } ・phpunit について書かれている......？  tree  composer.json  ・この composer.json というものは、Composer がインストールしてくる対象を決定している「何らかの定義」が書かれているファイルとして存在しています      ・ここに欲しいパッケージとそのバージョンを指定してあげるとよさそう      ・jsonの中身は、インストールするパッケージ : バージョンという書式  "phpunit/phpunit": "*"

・composer を実行できる環境を用意  tree  ・インストール対象を指定できたので、この状態でインストールを実行するとパッケージを取得できそうな気がしますよね？   

・composer を実行できる環境を用意  tree  ・インストール対象を指定できたので、この状態でインストールを実行するとパッケージを取得できそうな気がしますよね？      ・というわけで、この状態でdockerコンテナの中で composer install を実行   

・依存って何ですか？  . ├ Dockerfile ├ docker-compose.yml ├ composer.json ├ composer.lock
# New! └ vendor # New! ├ bin ├ composer ├ myclabs ├ nikic ├ phar-io ├ phpunit ├ sebastian └ theseer ・すると、左記のような構成に変化します  

# New! └ vendor # New! ├ bin ├ composer ├ myclabs ├ nikic ├ phar-io ├ phpunit ├ sebastian └ theseer ・すると、左記のような構成に変化します     ・composer install によって次の2つが増えた     　　・composer.lock    　　・vendor ディレクトリ  

# New! └ vendor # New! ├ bin ├ composer ├ myclabs ├ nikic ├ phar-io ├ phpunit ├ sebastian └ theseer ・すると、左記のような構成に変化します。     ・composer install によって次の2つが増えた     　　・composer.lock    　　・vendor ディレクトリ     ・vendor の中に phpunit がある‼  これ 

# New! └ vendor # New! ├ bin ├ composer　 ├ myclabs <- ? ├ nikic <- ? ├ phar-io <- ? ├ phpunit ├ sebastian <- ? └ theseer <- ? ・すると、左記のような構成に変化します。     ・composer install によって次の2つが増えた     　　・composer.lock    　　・vendor ディレクトリ     ・vendor の中に phpunit がある‼    ・とはいえ、他にもなんか色々ある  これ 

・依存って何ですか？  └ vendor └ phpunit ├ php-code-coverage ├ php-file-iterator ├
php-invoker ├ php-text-template ├ php-timer └ phpunit　　・vendor/phpunit を見てみると……  

・依存って何ですか？  └ vendor └ phpunit ├ php-code-coverage ├ php-file-iterator ├
php-invoker ├ php-text-template ├ php-timer └ phpunit　　・vendor/phpunit を見てみると……     ・さらに phpunit があった  これ 

・依存って何ですか？  └ vendor └ phpunit └ phpunit ├ schema ├
src ├ .phpstorm.meta.php ├ ChangeLog-10.1.md ├ composer.json ├ LICENCE ├ phpunit ├ phpunit.xsd ├ README.md └ SECURITY.md ・vendor/phpunit を見てみると……     ・さらに phpunit があった    ・というわけで中を見てみると…… 

・依存って何ですか？  └ vendor └ phpunit └ phpunit ├ schema ├
src ├ .phpstorm.meta.php ├ ChangeLog-10.1.md ├ composer.json ├ LICENCE ├ phpunit ├ phpunit.xsd ├ README.md └ SECURITY.md ・vendor/phpunit を見てみると……     ・さらに phpunit があった    ・というわけで中を見てみると……    ・ここにも composer.json があった  これ 

・依存って何ですか？  "require": { "php": ">=8.1", "ext-dom": "*", "ext-json": "*", "ext-libxml":
"*", "ext-mbstring": "*", "ext-xml": "*", "ext-xmlwriter": "*", "myclabs/deep-copy": "^1.10.1", "phar-io/manifest": "^2.0.3", "phar-io/version": "^3.0.2", "phpunit/php-code-coverage": "^10.1.1", "phpunit/php-file-iterator": "^4.0", "phpunit/php-invoker": "^4.0", "phpunit/php-text-template": "^3.0", "phpunit/php-timer": "^6.0", "sebastian/cli-parser": "^2.0", "sebastian/code-unit": "^2.0", "sebastian/comparator": "^5.0", "sebastian/diff": "^5.0", "sebastian/environment": "^6.0", "sebastian/exporter": "^5.0", "sebastian/global-state": "^6.0", "sebastian/object-enumerator": "^5.0", "sebastian/recursion-context": "^5.0", "sebastian/type": "^4.0", "sebastian/version": "^4.0" }, ・vendor/phpunit/phpunit/composer.json 

"*", "ext-mbstring": "*", "ext-xml": "*", "ext-xmlwriter": "*", "myclabs/deep-copy": "^1.10.1", "phar-io/manifest": "^2.0.3", "phar-io/version": "^3.0.2", "phpunit/php-code-coverage": "^10.1.1", "phpunit/php-file-iterator": "^4.0", "phpunit/php-invoker": "^4.0", "phpunit/php-text-template": "^3.0", "phpunit/php-timer": "^6.0", "sebastian/cli-parser": "^2.0", "sebastian/code-unit": "^2.0", "sebastian/comparator": "^5.0", "sebastian/diff": "^5.0", "sebastian/environment": "^6.0", "sebastian/exporter": "^5.0", "sebastian/global-state": "^6.0", "sebastian/object-enumerator": "^5.0", "sebastian/recursion-context": "^5.0", "sebastian/type": "^4.0", "sebastian/version": "^4.0" }, ・vendor/phpunit/phpunit/composer.json    ・myclubs, phar-io, sebastian がある    　　・これらは vendor に入ってた 

"*", "ext-mbstring": "*", "ext-xml": "*", "ext-xmlwriter": "*", "myclabs/deep-copy": "^1.10.1", "phar-io/manifest": "^2.0.3", "phar-io/version": "^3.0.2", "phpunit/php-code-coverage": "^10.1.1", "phpunit/php-file-iterator": "^4.0", "phpunit/php-invoker": "^4.0", "phpunit/php-text-template": "^3.0", "phpunit/php-timer": "^6.0", "sebastian/cli-parser": "^2.0", "sebastian/code-unit": "^2.0", "sebastian/comparator": "^5.0", "sebastian/diff": "^5.0", "sebastian/environment": "^6.0", "sebastian/exporter": "^5.0", "sebastian/global-state": "^6.0", "sebastian/object-enumerator": "^5.0", "sebastian/recursion-context": "^5.0", "sebastian/type": "^4.0", "sebastian/version": "^4.0" }, ・vendor/phpunit/phpunit/composer.json    ・myclubs, phar-io, sebastian がある    　　・これらは vendor に入ってた    ・確かに入ってる…… 

・依存って何ですか？  ここまでの流れを整理すると 

・依存って何ですか？  ここまでの流れを整理すると    ・composer を実行できる環境を用意した      

・依存って何ですか？  ここまでの流れを整理すると    ・composer を実行できる環境を用意した     ・composer.json にインストールするものを定義 (phpunit)
 

    ・composer install すると、composer.lock と vendor ディレクトリができた      

    ・composer install すると、composer.lock と vendor ディレクトリができた     ・vendor の中には phpunit を含むいくつかのパッケージが入ってた      

    ・composer install すると、composer.lock と vendor ディレクトリができた     ・vendor の中には phpunit を含むいくつかのパッケージが入ってた     ・phpunit の中には更に別の composer.json が入ってた      

    ・composer install すると、composer.lock と vendor ディレクトリができた     ・vendor の中には phpunit を含むいくつかのパッケージが入ってた     ・phpunit の中には更に別の composer.json が入ってた     ・その中には vendor に入ってた phpunit 以外のパッケージが指定されていた     　　・myclubs, phar-io, sebastian があった   

    ・composer install すると、composer.lock と vendor ディレクトリができた     ・vendor の中には phpunit を含むいくつかのパッケージが入ってた     ・phpunit の中には更に別の composer.json が入ってた     ・その中には vendor に入ってた phpunit 以外のパッケージが指定されていた     　　・myclubs, phar-io, sebastian があった    ここに注目 >

・依存って何ですか？  つまり、    　composer.json で指定したパッケージの中で、    　別の composer.json が更に他のパッケージを指定していた  
  ということ 

・依存って何ですか？  つまり、    　composer.json で指定したパッケージの中で、    　別の composer.json が更に他のパッケージを指定していた  
  ということ  phpunit を使うためには、 myclubs, phar-io, sebastian が必要で、これらを使うためには……　　> → composer install を実行すると、composer.json で定義されたパッケージが再帰的にインストールされていくということ  

・依存って何ですか？  すごく雑に説明すると…… 

・依存って何ですか？  すごく雑に説明すると……    ・composer.json に A を追加     

・依存って何ですか？  すごく雑に説明すると……    ・composer.json に A を追加    　　　　　　　　↓   
・A の中の composer.json には B がある  

・A の中の composer.json には B がある     　　　　　　　　↓    ・B の中の composer.json には C がある  

・A の中の composer.json には B がある     　　　　　　　　↓    ・B の中の composer.json には C がある　　→　　vendor に C を追加　  

・依存って何ですか？  すごく雑に説明すると……    ・composer.json に A を追加     　　　　　　　　↓
    ・A の中の composer.json には B がある　　　　　vendor に B を追加     　　　　　　　　↓　　　　　　　　　　　　　　　　　　　↑     ・B の中の composer.json には C がある　　→　　vendor に C を追加　  

・依存って何ですか？  すごく雑に説明すると……    ・composer.json に A を追加 vendor に A
を追加     　　　　　　　　↓ ↑     ・A の中の composer.json には B がある　　　　　vendor に B を追加     　　　　　　　　↓　　　　　　　　　　　　　　　　　　　↑     ・B の中の composer.json には C がある　　→　　vendor に C を追加　  

・依存って何ですか？  すごく雑に説明すると…… vendor の中に A, B, C が用意される！    ・composer.json
に A を追加 vendor に A を追加     　　　　　　　　↓ ↑     ・A の中の composer.json には B がある　　　　　vendor に B を追加     　　　　　　　　↓　　　　　　　　　　　　　　　　　　　↑     ・B の中の composer.json には C がある　　→　　vendor に C を追加　   だいたいこんなイメージ >

・依存って何ですか？  ここで、冒頭の依存とは何かという話に戻ると…… 

・依存って何ですか？  ここで、冒頭の依存とは何かという話に戻ると……    ・Aを使うにはBが必要で、Bを使うにはCが必要な時     　　・A ← B ←
C という依存関係が存在する    

C という依存関係が存在する     ・Aを composer.json で指定するだけで、↑の依存関係を自動で解決しつつインストールしてくれるのが composer ということ 

C という依存関係が存在する     ・Aを composer.json で指定するだけで、↑の依存関係を自動で解決しつつインストールしてくれるのが composer ということ  でもさぁ、  composer 使えるように設定する方が面倒くさくない？ 

C という依存関係が存在する     ・Aを composer.json で指定するだけで、↑の依存関係を自動で解決しつつインストールしてくれるのが composer ということ  でもさぁ、  composer 使えるように設定する方が面倒くさくない？  ↑ 　別の例を考えてみよう

・依存って何ですか？  ・ＡがBとEに依存する    ・BはCとFに依存する    ・CはDとEとGに依存する    ・DはFとHに依存する    ・Eは特に他のパッケージに依存しない
    ・FはIに依存する    ・JはEに依存する  指差確認しつつ、順番に入れていけばヨシッ！　　>  

    ・FはIに依存する    ・JはEに依存する  ・それぞれのパッケージは指定されたバージョンの範囲で定義されている・依存するパッケージが該当のバージョンで動くかどうかは要別途確認・なるべく新しいかつ安定しているバージョンのものを使いたい・あっ、D のバージョンはちょっと古いやつでよろしく ......　　> 

    ・FはIに依存する    ・JはEに依存する  ・それぞれのパッケージは指定されたバージョンの範囲で定義されている・依存するパッケージが該当のバージョンで動くかどうかは要別途確認・なるべく新しいかつ安定しているバージョンのものを使いたい・D のバージョンはちょっと古いやつで・それぞれのパッケージは指定されたバージョンの範囲で定義されている・依存するパッケージが該当のバージョンで動くかどうかは要別途確認・なるべく新しいかつ安定しているバージョンのものを使いたい・あっ、D のバージョンはちょっと古いやつでよろしく

・管理ツールって何ですか？  これまでのあらすじ 

・管理ツールって何ですか？  ・ユニットテストや静的解析、フレームワークなどのphp-src外のツールを広義の意味でパッケージと呼んでいた  これまでのあらすじ 

・管理ツールって何ですか？  ・ユニットテストや静的解析、フレームワークなどのphp-src外のツールを広義の意味でパッケージと呼んでいた    ・パッケージとパッケージの間には、依存関係があった  これまでのあらすじ 

・管理ツールって何ですか？  ・ユニットテストや静的解析、フレームワークなどのphp-src外のツールを広義の意味でパッケージと呼んでいた    ・パッケージとパッケージの間には、依存関係があった    ・依存関係を解決しつつ、必要なパッケージを自動でインストールしてくれるツールがあるらしい 
これまでのあらすじ 

  ・もちろん、バージョンの依存関係も解決できますよ  これまでのあらすじ 

  ・もちろん、バージョンの依存関係も解決できますよ  これまでのあらすじ  おいおい、マジかよ...... そんな夢のようなツールがあるのかよ >

・管理ツールって何ですか？  とはいえ......    それってパッケージインストールに必要な処理を自動化してるだけでは？ 

・管理ツールって何ですか？  とはいえ......    それってパッケージインストールに必要な処理を自動化してるだけでは？  管理ツールって言うには大袈裟かもしれない......ような......？  たしかに便利だけどさ >

・管理ツールって何ですか？  とはいえ......    それってパッケージインストールに必要な処理を自動化してるだけでは？  管理ツールって言うには大袈裟かもしれない......ような......？  おっ？ > composer を管理ツール
たらしめている理由が他にもあるはず…… 

・管理ツールって何ですか？  ここまでの流れを整理すると    ・composer を実行できる環境を用意した     ・composer.json にインストールするものを定義 (phpunit)
    ・composer install すると、composer.lock と vendor ディレクトリができた     ・vendor の中には phpunit を含むいくつかのパッケージが入ってた     ・phpunit の中には更に別の composer.json が入ってた     ・その中には vendor に入ってた phpunit 以外のパッケージが指定されていた     　　・myclubs, phar-io, sebastian があった    少し前のスライドに戻ってみると…… 

・管理ツールって何ですか？  ここまでの流れを整理すると    ・composer を実行できる環境を用意した     ・composer.json にインストールするものを定義 (phpunit)
    ・composer install すると、composer.lock と vendor ディレクトリができた    ・vendor の中には phpunit を含むいくつかのパッケージが入ってた     ・phpunit の中には更に別の composer.json が入ってた     ・その中には vendor に入ってた phpunit 以外のパッケージが指定されていた     　　・myclubs, phar-io, sebastian があった    少し前のスライドに戻ってみると……  ↑　これについて特に言及されていなかった……  

・管理ツールって何ですか？  ・composer installした際に誕生したもう一つのファイルである composer.lockとは何者？   

・管理ツールって何ですか？  ・composer installした際に誕生したもう一つのファイルである composer.lockとは何者？    ・よくわからんけど、composer.json に起因するものっぽいことは分かる    　　・composer.json
を使った composer install で誕生したので    

を使った composer install で誕生したので     ・とりあえず、composer.lock の中身を見てみればいいんじゃない？    

を使った composer install で誕生したので     ・とりあえず、composer.lock の中身を見てみればいいんじゃない？     Better Than Nothing ...... >

・管理ツールって何ですか？  composer.lock の中を見てみると以下のようなことが書いてある    

・管理ツールって何ですか？  composer.lock の中を見てみると以下のようなことが書いてある     "_readme": [ "This file locks
the dependencies of your project to a known state", "Read more about it at https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies", "This file is @generated automatically" ],

・管理ツールって何ですか？  composer.lock の中を見てみると以下のようなことが書いてある     "_readme": [ "This file locks
the dependencies of your project to a known state", "Read more about it at https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies", "This file is @generated automatically" ], 「このファイルは、プロジェクトの依存関係を既知の状態にロックします、このファイルは自動生成されます」  

・管理ツールって何ですか？  依存関係を既知の状態にロックしますとは......   

・管理ツールって何ですか？  依存関係を既知の状態にロックしますとは......    「このファイルが存在する状態で composer install を実行すると composer.json ではなくcomposer.lock
の方を参照してパッケージをインストールしてくる」ということ 

・管理ツールって何ですか？  依存関係を既知の状態にロックしますとは......    「このファイルが存在する状態で composer install を実行すると composer.json ではなくcomposer.lock
の方を参照してパッケージをインストールしてくる」ということ  というわけで、実験してみる  Better Than Nothing ...... >

・管理ツールって何ですか？  実際に、composer.json を以下の様に変更して再度 composer install を実行してみましょう  { "require-dev": { "phpunit/phpunit":
"*", "guzzlehttp/guzzle": "^6.3" } }    

"*", "guzzlehttp/guzzle": "^6.3" } }     すると、これまでの流れだとおそらく guzzleとguzzleの依存パッケージに関するディレクトリが vendor直下に追加されることが予想できます  

"*", "guzzlehttp/guzzle": "^6.3" } }     すると、これまでの流れだとおそらく guzzleとguzzleの依存パッケージに関するディレクトリが vendor直下に追加されることが予想できます   phpunit の時と同じはず >

・管理ツールって何ですか？  しかし、実際に続行してみると以下のようなエラー文が出て失敗します。    Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform. Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`. - Required (in require-dev) package "guzzlehttp/guzzle" is not present in the lock file.

Verifying lock file contents can be installed on current platform. Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`. - Required (in require-dev) package "guzzlehttp/guzzle" is not present in the lock file. 「composer.json と composer.lock で定義されている内容が違うぞ」  

Verifying lock file contents can be installed on current platform. Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`. - Required (in require-dev) package "guzzlehttp/guzzle" is not present in the lock file. 「composer.json と composer.lock で定義されている内容が違うぞ」   これが、プロジェクトの依存関係を既知の状態にロックしている状態というわけです。 

Verifying lock file contents can be installed on current platform. Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`. - Required (in require-dev) package "guzzlehttp/guzzle" is not present in the lock file. 「composer.json と composer.lock で定義されている内容が違うぞ」   これが、プロジェクトの依存関係を既知の状態にロックしている状態というわけです。  つまり、composer.lockファイルというのは  「現在のvendorの中身を正確に定義して固定しているもの」という理解ができます。 

Verifying lock file contents can be installed on current platform. Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`. - Required (in require-dev) package "guzzlehttp/guzzle" is not present in the lock file. 「composer.json と composer.lock で定義されている内容が違うぞ」   これが、プロジェクトの依存関係を既知の状態にロックしている状態というわけです。  つまり、composer.lockファイルというのは  「現在のvendorの中身を正確に定義して固定しているもの」という理解ができます。  composer installを実行した後で、lockファイルやvendorの中身を弄ったりしない限りはvendorの中身はlockファイルに描かれているもので保証されているというわけです。 

・管理ツールって何ですか？  Installing dependencies from lock file (including require-dev) Verifying lock
file contents can be installed on current platform. Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`. - Required (in require-dev) package "guzzlehttp/guzzle" is not present in the lock file. というわけでここに書かれている通り、  composer updateを実行してcomposer.lockの内容を上書きしてみましょう。   

・管理ツールって何ですか？  . └ vendor ├ bin ├ composer ├ guzzlehttp
├ myclabs ├ nikic ├ phar-io ├ phpunit ├ psr ├ ralouphie ├ sebastian ├ sumfony └ theseer ・すると、左記のような構成に変化します    

<- New! ├ myclabs ├ nikic ├ phar-io ├ phpunit ├ psr <- New! ├ ralouphie <- New! ├ sebastian ├ sumfony <- New! └ theseer ・すると、左記のような構成に変化します     ・たしかに、guzzlehttpと依存パッケージがいくつか追加されている 

<- New! ├ myclabs ├ nikic ├ phar-io ├ phpunit ├ psr <- New! ├ ralouphie <- New! ├ sebastian ├ sumfony <- New! └ theseer ・すると、左記のような構成に変化します     ・たしかに、guzzlehttpと依存パッケージがいくつか追加されている    ・この状態でvendorディレクトリを削除し、   composer install を行ってみると同じ状況が再現されることも確認 

・管理ツールって何ですか？  なので、composer.json, composer.lock の役割についてまとめると以下の様になります    

・管理ツールって何ですか？  なので、composer.json, composer.lock の役割についてまとめると以下の様になります     ・初回の composer install では
.json を参照    ・二回目以降は .lock を参照   

.json を参照    ・二回目以降は .lock を参照    上記に関しては嬉しいこととしては次のような点があります 

.json を参照    ・二回目以降は .lock を参照    上記に関しては嬉しいこととしては次のような点があります    ・チーム開発などでパッケージの依存関係に関する情報を共有したい場合    ・誰かが用意した composer.lock を git等で管理し、各自の環境で composer install することにより共通の開発環境を手軽に用意可能 

・管理ツールって何ですか？  というわけで、  composer は PHPのパッケージ依存管理ツールであることが分かった   

  パッケージってなんですか？  依存ってなんですか？   管理ツールってなんですか？  まだ何かあるような気がします！  >  あいえるたそ 

・まだ何かあるような気がします！　~ require ~  とはいえ、追加でパッケージが欲しい時に、composer.jsonに必要なパッケージを書き込んで composer updateするという手順を取りたくないときもあると思います     

・まだ何かあるような気がします！　~ require ~  とはいえ、追加でパッケージが欲しい時に、composer.jsonに必要なパッケージを書き込んで composer updateするという手順を取りたくないときもあると思います    それはどんなときかというと、 
  「追加パッケージに関係のないパッケージのバージョンを動かしたくない」    等の場合が一例としてあります   

・まだ何かあるような気がします！　~ require ~  とはいえ、追加でパッケージが欲しい時に、composer.jsonに必要なパッケージを書き込んで composer updateするという手順を取りたくないときもあると思います    それはどんなときかというと、 
  「追加パッケージに関係のないパッケージのバージョンを動かしたくない」    等の場合が一例としてあります      そこで使うコマンドが、 composer require <パッケージ名>  

・まだ何かあるような気がします！　~ require ~  試しに、  composer require monolog/monolog   を実行すると、composer.json に
monolog に関する定義が追加されていることが確認できます       { "require-dev": { "phpunit/phpunit": "*", "guzzlehttp/guzzle": "^6.3" }, "require": { "monolog/monolog": "^3.3" } }

・まだ何かあるような気がします！　~ require ~  { "require-dev": { "phpunit/phpunit": "*", "guzzlehttp/guzzle": "^6.3"
}, "require": { "monolog/monolog": "^3.3" } } ・ここで “require” となっているのは、本番環境で必要とされるパッケージ群を定義している       ・” require-dev “ と書いてある方は開発環境で必要となるパッケージの定義  

・まだ何かあるような気がします！　~ require ~  { "require-dev": { "phpunit/phpunit": "*", "guzzlehttp/guzzle": "^6.3"
}, "require": { "monolog/monolog": "^3.3" } } ・ここで “require” となっているのは、本番環境で必要とされるパッケージ群を定義している       ・” require-dev “ と書いてある方は開発環境で必要となるパッケージの定義   ・devの方には composer require --dev <パッケージ名> としてあげることで追加できる     ・この状態で何も指定せずにcomposer installを実行すると、requireもrequire-devもどちらもインストールされる     ・composer install --no-dev とすると、require-devの記載分を除く本番環境用だけをインストールする  

  パッケージってなんですか？  依存ってなんですか？   管理ツールってなんですか？  まだ何かあるような気がします！！  >  あいえるたそ 

・まだ何かあるような気がします！　~ プロジェクトとパッケージ ~  ・そもそも、composer.jsonをディレクトリに配置した時点で、そのディレクトリは1つのパッケージになると考えてよさそう       

・まだ何かあるような気がします！　~ プロジェクトとパッケージ ~  ・そもそも、composer.jsonをディレクトリに配置した時点で、そのディレクトリは1つのパッケージになると考えてよさそう      ・つまり、requireをプロジェクトに追加するとき、その行為自体が「他のパッケージに依存するパッケージ」を新たに作っているとも考えられる
   

・まだ何かあるような気がします！　~ プロジェクトとパッケージ ~  ・そもそも、composer.jsonをディレクトリに配置した時点で、そのディレクトリは1つのパッケージになると考えてよさそう      ・つまり、requireをプロジェクトに追加するとき、その行為自体が「他のパッケージに依存するパッケージ」を新たに作っているとも考えられる
      ・上記を踏まえてプロジェクトとパッケージの違いは何なのか考えてみると、「プロジェクトは名前のないパッケージ」だと解釈できそう    

・まだ何かあるような気がします！　~ プロジェクトとパッケージ ~  具体例として下に書いてあるcomposer.jsonを例に考えてみよう     すると、これはphpunit, guzzle, monologが入ったパッケージを定義しているのと同じであることが分かる  
  とはいえ、この例ではプロジェクトと呼ぶにはなんかちょっと足りてない感じがする         { "require-dev": { "phpunit/phpunit": "*", "guzzlehttp/guzzle": "^6.3" }, "require": { "monolog/monolog": "^3.3" } }

・まだ何かあるような気がします！　~ プロジェクトとパッケージ ~  インストール可能なパッケージを作成するためには、このパッケージ定義に名前を付けてあげる必要がある    たとえば、phpunitであればphpunit/phpunitとなっている部分を指定してあげる感じ         
  { "name": "kerokero/hello-composer",　 "require-dev": { "phpunit/phpunit": "*", "guzzlehttp/guzzle": "^6.3" }, "require": { "monolog/monolog": "^3.3" } }

・まだ何かあるような気がします！　~ プロジェクトとパッケージ ~  ・この例では、プロジェクト名が kerokero/hello-composer であり、ベンダー名が kerokero、  パッケージ名が hello-composer ということになります。 
        "name": "kerokero/hello-composer",　

・まだ何かあるような気がします！　~ プロジェクトとパッケージ ~  ・この例では、プロジェクト名が kerokero/hello-composer であり、ベンダー名が kerokero、  パッケージ名が hello-composer ということになります。 
  ・作ったライブラリはPackagistなどのレポジトリに登録することができ、誰でも簡単に使うことができるようになる    ・なので、これまでcomposer installでインストールしていたパッケージは、このような形で誰かが作ったものであるということを知っておくと良いかも        "name": "kerokero/hello-composer",　

・まだ何かあるような気がします！　~ プロジェクトとパッケージ ~  ・また、composerにはプラットフォームパッケージという概念もある    ・これはシステムにインストールされる仮想的なパッケージのことであり、   具体的にはphpやcurlなどがあり
"php" : "^5.5 || ^7.0", などという形で指定することができる     ・これらは別途誰かが作ったパッケージというよりは、仮想的にcomposerでインストールできるようにパッケージ化しているものと考えてよさそう          { "require": { "php": ">=5.3" } }

Agenda  1.　軽い自己紹介　　　　　　　　　　    2.　Composerってなによ　　　　　　　    3.　パッケージ管理ツールとしてのComposer　    4.　pharについて　　　　　　　　　    5.　オートロードについて 

・pharについて  少しスライドを戻ってみましょう 

・pharについて  少しスライドを戻ってみましょう  PHPUnit に必要なすべての依存ファイルをひとつのファイルにまとめた PHP アーカイブ (PHAR)
を配布します      あるいは、Composer を使って PHPUnit やその依存ファイルをダウンロードしてインストールすることもできます。 

・pharについて  ・この説明を見る限り......      PHPUnit に必要なすべての依存ファイルをひとつのファイルにまとめた PHP アーカイブ
(PHAR) を配布します

・pharについて  ・この説明を見る限り......      ・pharは依存パッケージをまとめて配布するためのものであると考えてよさそう      PHPUnit に必要なすべての依存ファイル
をひとつのファイルにまとめた PHP アーカイブ (PHAR) を配布します

・pharについて  ・この説明を見る限り......      ・pharは依存パッケージをまとめて配布するためのものであると考えてよさそう      ・つまり、zipやtarの様に複数のPHPファイルを1つにまとめられると考えてよさそう   
  PHPUnit に必要なすべての依存ファイルをひとつのファイルにまとめた PHP アーカイブ (PHAR) を配布します

・pharについて  ・この説明を見る限り......      ・pharは依存パッケージをまとめて配布するためのものであると考えてよさそう      ・つまり、zipやtarの様に複数のPHPファイルを1つにまとめられると考えてよさそう   
  ・.pharファイルというのは上記の通り、PHPUnitなどのパッケージを  まとめてアーカイブ化した現物を提供するための定義であると考えられる     

・pharについて  ・しかし、composer.jsonやlockを使ってinstallできる状態で、いったいphar を使う意味とは何なのでしょうか？         

・pharについて  ・しかし、composer.jsonやlockを使ってinstallできる状態で、いったいphar を使う意味とは何なのでしょうか？      ・例えば、pharでまとめなかったとしても   composer require --dev
<パッケージ名>   で開発時にのみ使う依存パッケージをインストールできます           

・pharについて  ・しかし、composer.jsonやlockを使ってinstallできる状態で、いったいphar を使う意味とは何なのでしょうか？      ・例えば、pharでまとめなかったとしても   composer require --dev
<パッケージ名>   で開発時にのみ使う依存パッケージをインストールできます      ・これは便利だし、直感的にも何をしているかわかりやすい  のでこれでよさそうな気がしますよね。    よね >

・pharについて  ・多くのプロジェクトはツール単体で開発されているわけではなく、  ツール自体も他のパッケージに依存しているということはこれまでの話からも理解できていると思います           

・pharについて  ・多くのプロジェクトはツール単体で開発されているわけではなく、  ツール自体も他のパッケージに依存しているということはこれまでの話からも理解できていると思います      ・例えば……  コードフォーマッタである PHP-CS-Fixer は多くの
Symfony コンポーネントに依存しているので、何かの事情で古いバージョンに依存しているパッケージがインストールできない場合などがあります         

・pharについて  ・多くのプロジェクトはツール単体で開発されているわけではなく、  ツール自体も他のパッケージに依存しているということはこれまでの話からも理解できていると思います      ・例えば……  コードフォーマッタである PHP-CS-Fixer は多くの
Symfony コンポーネントに依存しているので、何かの事情で古いバージョンに依存しているパッケージがインストールできない場合などがあります    ・ツールを含めた依存パッケージを全て同時にバージョン管理する必要があるため、ライブラリの依存関係がrequire-devのみで解決することができずにプロダクトで使われているパッケージ全体に問題が波及してしまう    つらい >

・pharについて  ・Composer自体も composer.phar というファイルで配布されていたり、  PHPUnit などもPharファイルとして配布されています。    ・これらは Composer の依存関係(vendor/ディレクトリ)を丸ごと同梱しているので、個々人
が composer install などで各依存をかき集めることなく完成品のパッケージをインストールできるわけです。           

Agenda  1.　軽い自己紹介　　　　　　　　　　    2.　Composerってなによ　　　　　　　    3.　パッケージ管理ツールとしてのComposer　    4.　pharについて　　　　　　　　　    5.　オートロードについて　　　　　 

・オートロードについて  ・ここまでがパッケージ管理ツールとしての Composer の役割でした         
     

・オートロードについて  ・ここまでがパッケージ管理ツールとしての Composer の役割でした    ・そして実は、もうひとつの Composer の役割として
autoloader という役割があります。               

・オートロードについて  ・ここまでがパッケージ管理ツールとしての Composer の役割でした    ・そして実は、もうひとつの Composer の役割として
autoloader という役割があります。    なので、ここからはオートロードとPSRについて話します。           

・オートロードについて  ・Composerを使う際にも登場するワードとしてオートロードというものがあります                 
     

・オートロードについて  ・Composerを使う際にも登場するワードとしてオートロードというものがあります      ・オートロードが何なのかはさておき、序盤の方でcomposer installをした際にvendorディレクトリの中に実はautoload.phpも自動生成されていました       
       

・オートロードについて  ・Composerを使う際にも登場するワードとしてオートロードというものがあります      ・オートロードが何なのかはさておき、序盤の方でcomposer installをした際にvendorディレクトリの中に実はautoload.phpも自動生成されていました       
        . └ vendor ├ bin ├ composer : └ autoload.php # New!

・オートロードについて  ・このautoload.phpの中身を見てみると……                 
     

・オートロードについて  ・このautoload.phpの中身を見てみると……                 
      何やらcomposerの中のファイルを呼び出している

・オートロードについて  ・というわけで、どうやらオートロードという概念がcomposerを使う上で必要になりそうなことがなんとなく分かってきました               
       

・オートロードについて  ・というわけで、どうやらオートロードという概念がcomposerを使う上で必要になりそうなことがなんとなく分かってきました      ・とはいえ、このオートロードという仕組みはComposerに固有のものではなく、実は PHP自体に備わっている仕組みみたいです     
           

・オートロードについて  ・というわけで、どうやらオートロードという概念がcomposerを使う上で必要になりそうなことがなんとなく分かってきました      ・とはいえ、このオートロードという仕組みはComposerに固有のものではなく、実は PHP自体に備わっている仕組みみたいです     
・なので、まずはPHPのオートロードの仕組みから見ていこうと思います         

・オートロードについて  ・PHPはオブジェクト指向言語でもあるため、アプリケーションで使われるクラスの定義ごとに一つのPHPソースファイルを作成していくことになります             
         

・オートロードについて  ・PHPはオブジェクト指向言語でもあるため、アプリケーションで使われるクラスの定義ごとに一つのPHPソースファイルを作成していくことになります      ・その際に問題になる点としては、各スクリプトの先頭に必要な読み込みを行うための長いリストを記述する必要があることが挙げられます。    
           

・オートロードについて  ・PHPはオブジェクト指向言語でもあるため、アプリケーションで使われるクラスの定義ごとに一つのPHPソースファイルを作成していくことになります      ・その際に問題になる点としては、各スクリプトの先頭に必要な読み込みを行うための長いリストを記述する必要があることが挙げられます。    
・オートロードを使用しない具体的な例としては、依存するクラスを require_once __DIR__.'../classes/A.php'; などとして冒頭で呼んであげるなどがあります。        

・オートロードについて  ・オートロードしない場合の流れは、実際には次のようになります               
        <?php class A{ public $name = ""; public function __construct() { $this->name = "kerokero"; } public function Hello() { echo $this->name."\n"; } } <?php require_once __DIR__.'/../classes/A.php'; class B extends A{ public $email = ""; public function Send() { echo "Send mail to ".$this->email."\n"; } } <?php require_once __DIR__.'/classes/B.php'; $b = new B(); $b->Hello(); $b->Send(); A.php B.php main.php

・オートロードについて  では、オートロードを使うとどんなかんじになるのでしょうか？              

・オートロードについて  では、オートロードを使うとどんなかんじになるのでしょうか？オートロードを使う時の挙動を確認する前にいくつか知っておかなければならないことがあるので、そちらを先に紹介します        

・オートロードについて　~ PSR ~　  ・PHPにも推奨されるコード規約というものがある            
             

・オートロードについて　~ PSR ~　  ・PHPにも推奨されるコード規約というものがある     ・しかし、PHPの公式が出しているものというわけではなく、PHPのフレームワーク等の開発者有志のグループであるPHP-FIGによって策定されているコーディング規約があります   
　　・それがPSR(PHP Standarrd Recommendations)     　　・多くのPHPライブラリはこの考え方に則って作られている          

・オートロードについて　~ PSR ~　  ・PHPにも推奨されるコード規約というものがある     ・しかし、PHPの公式が出しているものというわけではなく、PHPのフレームワーク等の開発者有志のグループであるPHP-FIGによって策定されているコーディング規約があります   
　　・それがPSR(PHP Standarrd Recommendations)     　　・多くのPHPライブラリはこの考え方に則って作られている     ・そして、Composerも類を洩れずこれに従っている。   実際、Composerは名前空間に関する規約であるPSR-4 に従っています。    name space >

  名前空間ってなんですか？  >  あいえるたそ 

・オートロードについて　~ 名前空間 ~　  ・ここでは名前空間については深く触れずに、簡単に説明しようと思います            
           

・オートロードについて　~ 名前空間 ~　  ・ここでは名前空間については深く触れずに、簡単に説明しようと思います     ・例えば、main.php で itemShop.php から
getItem関数を呼ぶとします                     

・オートロードについて　~ 名前空間 ~　  ・ここでは名前空間については深く触れずに、簡単に説明しようと思います     ・例えば、main.php で itemShop.php から
getItem関数を呼ぶとします      ・おそらく、  require_once("itemShop.php);   　として main.php 内で getItem関数を呼ぶことで解決できます             　まあね　>

・オートロードについて　~ 名前空間 ~　  ・では、main.php で treasureBox.php から getItem 関数も呼びたくなったとしましょう  
                 

・オートロードについて　~ 名前空間 ~　  ・では、main.php で treasureBox.php から getItem 関数も呼びたくなったとしましょう・この時、関数名が同じなので衝突してしまい実行できません。
　　・二重定義のエラーが出てしまいます              

　　・二重定義のエラーが出てしまいます・そこで、この現象を回避するために名前空間というものを用意します          

　　・二重定義のエラーが出てしまいます・そこで、この現象を回避するために名前空間というものを用意します   ・それぞれに ItemShop と TreasureBox という名前空間を与えると、それぞれの関数は   ItemShop/getItem、TreasureBox/getItem と異なる塊にすることができます。      

・オートロードについて　~ 名前空間 ~　  ・そして、この名前空間による制御も開発規模が大きくなってくると、名前空間自体の管理を上手くやる必要があります。         
             

・オートロードについて　~ 名前空間 ~　  ・そして、この名前空間による制御も開発規模が大きくなってくると、名前空間自体の管理を上手くやる必要があります。      ・手動で管理するとめんどいので、これを自動でやってくれる機能があれば便利です。 
               

・オートロードについて　~ 名前空間 ~　  ・そして、この名前空間による制御も開発規模が大きくなってくると、名前空間自体の管理を上手くやる必要があります。      ・手動で管理するとめんどいので、これを自動でやってくれる機能があれば便利です。 
    ・それを解決するのがオートローディングの考え方になっています。            へぇ～ >

  PSR-4でオートローディングに関して重要な部分　  　　　　　　　　　　　　　　　　　が気になります！    >  あいえるたそ 

・オートロードについて　~ PSR-4 ~　  ・というわけで、名前空間の利用価値が分かったので、名前空間を定義した状態でクラスをオートロードできるようにしてあげたいですね         
             

・オートロードについて　~ PSR-4 ~　  ・というわけで、名前空間の利用価値が分かったので、名前空間を定義した状態でクラスをオートロードできるようにしてあげたいですね        ・Composerの場合はPSR-4に準拠しているので、PSR-4の中の一文を見てみます
                 

                  The terminating class name corresponds to a file name ending in .php. The file name MUST match the case of the terminating class name.

                  The terminating class name corresponds to a file name ending in .php. The file name MUST match the case of the terminating class name. 「クラス名は .php で終わるファイル名に対応します。ファイル名は、クラス名の大文字小文字と一致しなければなりません (MUST)」 

・オートロードについて　~ PSR-4 ~　  ・PSR-4に従う以上何かメリットがあるはずですが、とりあえずここでわかるのは、   ファイルをクラスの様に扱っているということです。       
               

・オートロードについて　~ PSR-4 ~　  ・PSR-4に従う以上何かメリットがあるはずですが、とりあえずここでわかるのは、   ファイルをクラスの様に扱っているということです。     
  　　　  　　　というわけで実際にcomposerのオートロードを見ていきましょう             

・オートロードについて　~ composerのオートロード ~　  ・少しスライドを戻してみましょう            
              何やらcomposerの中のファイルを呼び出している

こっちがautoload.phpから呼ばれてる   おっ >

・PHPのオートロードは spl_autoload_register を使って登録されるらしい    ・引数としてautoload関数を与えてあげるとキューの中に追加されていき、定義された順に紐づけられていくみたいです    
・とはいえ、php-srcの中に踏み込むことになるのでここでは詳細は触れません   正直、よく分からん >

　　　　おっおっ > なんか include してファイルを読み込んでる  ・ClassLoaderのコンストラクタで呼ばれているinitializeIncludeClosure の中を見てみる    
・特定のファイルをincludeしていることも理解できる

・$file の中身は vendor/composer/autoload_real.php の中で指定されていて、 ComposerStaticInit<値> となっていることが分かります  正直、よく分からん >

vendor/composer/autoload_static.php ・vendor/composer/autoload_static.php の中を見てみると、確かにcomposer.lockに書かれているものたちが public static $classMap として設定されている       

vendor/composer/autoload_static.php ・vendor/composer/autoload_static.php の中を見てみると、確かにcomposer.lockに書かれているものたちが public static $classMap として設定されている      ・たしかに
名前空間 => ファイルパスというようにマッピングされていることが分かります 

・オートロードについて　~ composerのオートロード ~　  ・なので、このことからも composerのオートロードがやっていることは    「クラスが入ってるファイルのパスを名前空間に紐づけているだけ」    ということがなんとなく分かったと思います 
                 

・オートロードについて　~ composerのオートロード ~　  ・なので、このことからも composerのオートロードがやっていることは    「クラスが入ってるファイルのパスを名前空間に紐づけているだけ」    ということがなんとなく分かったと思います 
    ・この autoload_static.php の $classmap の中を見ると、確かにこれだけの量のクラスをいちいち require する必要があると考えれば、オートロードが便利だということもなんとなく分かると思います             

  理屈は分かったけどいまいちピンとこない！  　　　　　　　　　　　　　　　　    >  　　　猫 

  5.5　Slim Framework　の場合　    6.　反省点・良かった点・感想 

・Slim Framework の場合  ・これまでの説明で、composer とそれに採用されている autoload が便利なことはなんとなく分かります     
                   

・とはいえ、いまいちまだピンときていない部分もあるので、実際に Slim Frameworkのコードを見てみることで実感してみます      ・最初の方で使っていた composer.json に Slim Framework を追加します。  composer require slim/slim で require に追加し、composer update を行い composer.lock にSlim Framework を入れます         

・とはいえ、いまいちまだピンときていない部分もあるので、実際に Slim Frameworkのコードを見てみることで実感してみます      ・最初の方で使っていた composer.json に Slim Framework を追加します。  composer require slim/slim で require に追加し、composer update を行い composer.lock にSlim Framework を入れます      ・同様にして composer require slim/psr7 も入れます。  そして、composer install を実行すると確かに vendor ディレクトリの中に slim が誕生していることが確認できます (画像割愛) 

・Slim Framework の場合  ・この状態で以下の様に html/index.php を用意してみます         
                 

                  ・アクセスしてみると、たしかにslimを使って書かれた情報が返却されます    ・コードを見ると /../vendor/autoload.php をrequireしていることが分かります    ・composer でオートロードされたクラスを、use Slim\Factory\AppFactory; のようにして呼び出しているということになります 

                  ・アクセスしてみると、たしかにslimを使って書かれた情報が返却されます    ・コードを見ると /../vendor/autoload.php をrequireしていることが分かります    ・composer でオートロードされたクラスを、use Slim\Factory\AppFactory; のようにして呼び出しているということになります  おお！ >

  5.5　Slim Framework　の場合　    6.　反省点・良かった点・感想　　　 

・反省点・良かった点・感想  ・Composerってチーム業務で当たり前のように使ってたり、PHPを使う様々な文脈で当然の用にでてくるけどなんかよく分かってないなーと思ったので調べたけど、理解が深まってよかった。               
         

・反省点・良かった点・感想  ・Composerってチーム業務で当たり前のように使ってたり、PHPを使う様々な文脈で当然の用にでてくるけどなんかよく分かってないなーと思ったので調べたけど、理解が深まってよかった。      ・実際にコードの中身を覗いてみると挙動の一部を理解することができた気がした。        
           

・反省点・良かった点・感想  ・Composerってチーム業務で当たり前のように使ってたり、PHPを使う様々な文脈で当然の用にでてくるけどなんかよく分かってないなーと思ったので調べたけど、理解が深まってよかった。      ・実際にコードの中身を覗いてみると挙動の一部を理解することができた気がした。       ・php-src
が絡む部分はよく分からなくて、あまり理解できなかったのが残念               

・反省点・良かった点・感想  ・2024年1月開催の phpcon北海道のLTで少しお話しさせていただきます！気になります！　>

今回の反省点・分かった点・感想 https://zenn.dev/22kerokero22/articles/3878a14202da4f ・今回の発表と似たような内容が、 zenn の記事でもまとめられているのでそちらも参照してみよう

ご清聴ありがとうございました!!  わたし、　　　　    を完全理解しました！

phpconJapan2023 わたし、Composerが気になります！

phpconJapan2023 わたし、Composerが気になります！

More Decks by kero kero

Featured

Transcript