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

by kero kero

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

どうも、kerokero です。 

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

とは？ 

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

ある日のこと…… 

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

というわけで、 

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

・依存って何ですか？  ・ひとまず前提知識として    　　・composer 自身も1つのパッケージであることは分かる    　　　　・php-src に含まれている機能ではないということ    　　・composer をインストールしてくる必要がある  　　　　  　　　　・とりあえずdockerコンテナでcomposer環境を試す 

Slide 54

Slide 54 text

・依存って何ですか？  ・ひとまず前提知識として    　　・composer 自身も1つのパッケージであることは分かる    　　　　・php-src に含まれている機能ではないということ    　　・composer をインストールしてくる必要がある  　　　　  　　　　・とりあえずdockerコンテナでcomposer環境を試す  頭の中に思い浮かべてみよう >

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

Slide 60

Slide 60 text

・依存って何ですか？  . ├ Dockerfile ├ docker-compose.yml └ composer.json # New! ・composer を実行できる環境を用意  tree  ・インストール対象を指定できたので、この状態でインストールを実行するとパッケージを取得できそうな気がしますよね？   

Slide 61

Slide 61 text

・依存って何ですか？  . ├ Dockerfile ├ docker-compose.yml └ composer.json # New! ・composer を実行できる環境を用意  tree  ・インストール対象を指定できたので、この状態でインストールを実行するとパッケージを取得できそうな気がしますよね？      ・というわけで、この状態でdockerコンテナの中で composer install を実行   

Slide 62

Slide 62 text

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

・依存って何ですか？  └ 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 があった    ・というわけで中を見てみると…… 

Slide 69

Slide 69 text

Slide 70

Slide 70 text

・依存って何ですか？  "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 

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

Slide 78

Slide 78 text

・依存って何ですか？  ここまでの流れを整理すると    ・composer を実行できる環境を用意した     ・composer.json にインストールするものを定義 (phpunit)     ・composer install すると、composer.lock と vendor ディレクトリができた     ・vendor の中には phpunit を含むいくつかのパッケージが入ってた     ・phpunit の中には更に別の composer.json が入ってた      

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

・依存って何ですか？  ここで、冒頭の依存とは何かという話に戻ると……    ・Aを使うにはBが必要で、Bを使うにはCが必要な時     　　・A ← B ← C という依存関係が存在する     ・Aを composer.json で指定するだけで、↑の依存関係を自動で解決しつつインストールしてくれるのが composer ということ 

Slide 94

Slide 94 text

・依存って何ですか？  ここで、冒頭の依存とは何かという話に戻ると……    ・Aを使うにはBが必要で、Bを使うにはCが必要な時     　　・A ← B ← C という依存関係が存在する     ・Aを composer.json で指定するだけで、↑の依存関係を自動で解決しつつインストールしてくれるのが composer ということ  でもさぁ、  composer 使えるように設定する方が面倒くさくない？ 

Slide 95

Slide 95 text

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

Slide 117

Slide 117 text

・管理ツールって何ですか？  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" ], 「このファイルは、プロジェクトの依存関係を既知の状態にロックします、このファイルは自動生成されます」  

Slide 118

Slide 118 text

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

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

・管理ツールって何ですか？  実際に、composer.json を以下の様に変更して再度 composer install を実行してみましょう  { "require-dev": { "phpunit/phpunit": "*", "guzzlehttp/guzzle": "^6.3" } }     すると、これまでの流れだとおそらく guzzleとguzzleの依存パッケージに関するディレクトリが vendor直下に追加されることが予想できます  

Slide 123

Slide 123 text

Slide 124

Slide 124 text

Slide 125

Slide 125 text

Slide 126

Slide 126 text

Slide 127

Slide 127 text

・管理ツールって何ですか？  しかし、実際に続行してみると以下のようなエラー文が出て失敗します。    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 `. - Required (in require-dev) package "guzzlehttp/guzzle" is not present in the lock file. 「composer.json と composer.lock で定義されている内容が違うぞ」   これが、プロジェクトの依存関係を既知の状態にロックしている状態というわけです。  つまり、composer.lockファイルというのは  「現在のvendorの中身を正確に定義して固定しているもの」という理解ができます。 

Slide 128

Slide 128 text

Slide 129

Slide 129 text

・管理ツールって何ですか？  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 `. - Required (in require-dev) package "guzzlehttp/guzzle" is not present in the lock file. というわけでここに書かれている通り、  composer updateを実行してcomposer.lockの内容を上書きしてみましょう。   

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

・管理ツールって何ですか？  なので、composer.json, composer.lock の役割についてまとめると以下の様になります     ・初回の composer install では .json を参照    ・二回目以降は .lock を参照    上記に関しては嬉しいこととしては次のような点があります 

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

Slide 145

Slide 145 text

・まだ何かあるような気がします！　~ 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の記載分を除く本番環境用だけをインストールする  

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

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

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

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

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

Slide 170

Slide 170 text

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

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

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

Slide 175

Slide 175 text

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

Slide 176

Slide 176 text

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

Slide 177

Slide 177 text

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

Slide 178

Slide 178 text

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

Slide 179

Slide 179 text

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

Slide 180

Slide 180 text

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

Slide 181

Slide 181 text

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

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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

Slide 184

Slide 184 text

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

Slide 185

Slide 185 text

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

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

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

Slide 193

Slide 193 text

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

Slide 194

Slide 194 text

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

Slide 195

Slide 195 text

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

Slide 196

Slide 196 text

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

Slide 197

Slide 197 text

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

Slide 198

Slide 198 text

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

Slide 199

Slide 199 text

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

Slide 200

Slide 200 text

・オートロードについて　~ 名前空間 ~　  ・では、main.php で treasureBox.php から getItem 関数も呼びたくなったとしましょう・この時、関数名が同じなので衝突してしまい実行できません。　　・二重定義のエラーが出てしまいます・そこで、この現象を回避するために名前空間というものを用意します   ・それぞれに ItemShop と TreasureBox という名前空間を与えると、それぞれの関数は   ItemShop/getItem、TreasureBox/getItem と異なる塊にすることができます。      

Slide 201

Slide 201 text

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

Slide 202

Slide 202 text

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

Slide 203

Slide 203 text

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

Slide 204

Slide 204 text

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

Slide 205

Slide 205 text

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

Slide 206

Slide 206 text

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

Slide 207

Slide 207 text

・オートロードについて　~ 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.

Slide 208

Slide 208 text

Slide 209

Slide 209 text

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

Slide 210

Slide 210 text

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

Slide 211

Slide 211 text

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

Slide 212

Slide 212 text

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

Slide 213

Slide 213 text

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

Slide 214

Slide 214 text

Slide 215

Slide 215 text

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

Slide 216

Slide 216 text

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

Slide 217

Slide 217 text

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

Slide 218

Slide 218 text

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

Slide 219

Slide 219 text

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

Slide 220

Slide 220 text

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

Slide 221

Slide 221 text

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

Slide 222

Slide 222 text

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

Slide 223

Slide 223 text

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

Slide 224

Slide 224 text

・Slim Framework の場合  ・これまでの説明で、composer とそれに採用されている autoload が便利なことはなんとなく分かります      ・とはいえ、いまいちまだピンときていない部分もあるので、実際に Slim Frameworkのコードを見てみることで実感してみます      ・最初の方で使っていた composer.json に Slim Framework を追加します。  composer require slim/slim で require に追加し、composer update を行い composer.lock にSlim Framework を入れます         

Slide 225

Slide 225 text

Slide 226

Slide 226 text

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

Slide 227

Slide 227 text

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

Slide 228

Slide 228 text

Slide 229

Slide 229 text

Slide 230

Slide 230 text

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

Slide 231

Slide 231 text

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

Slide 232

Slide 232 text

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

Slide 233

Slide 233 text

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

Slide 234

Slide 234 text

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

Slide 235

Slide 235 text

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