【20日目】知識を付け直す【作曲の補助ツールを作るまでの日記】

2023年10月28日~2023年11月20日

最近、長めの個人的なイベントがあり、2週間色々学ばせていただいた。

そこで学んだことを色々取り入れたい。

現在のLaravelプロジェクトに対して色んな不安要素・改善点はあるんだけど、とりあえず以下のことをやりたい。

共有フォルダを使う
PhpStormを使う
Githubでプロジェクトをprivateにする
全体的なコードのリファクタリング
テストコードを増やす
Duskというブラウザテストを作る
コメントしっかり書く
PHPDocを書く
コードの整形
PhpStorm上の警告処理
コンソール上の警告処理
telescopeを使う
論理削除の実装
名前の仕組みを変更

なんなら、Laravelのプロジェクトを作り直してもいいなぁと思ってたりする。

あと、Composerとかnpmらへんで躓いたとこがあって、ちょっとそこらへんの理解も足りないなぁと思ったりしたからそこら辺もやりたい。

とりあえず、VMとの共有フォルダ・PhpStorm・Githubかなぁ。

共有フォルダにする(最終的に共有フォルダはバグ出すぎて諦めた)
1. GuestAddtionsを入れる
PhpStormを使う
1. PhpStormのインストール
2. 初期設定
PhpStormと新規Laravelプロジェクト
ApacheにLaravelプロジェクトを認識してもらう
再現していく
最後にPhpStormを初音ミク＆重音テト色にする
1. PhpStormとVSCodeの比較
2. やり方

共有フォルダにする(最終的に共有フォルダはバグ出すぎて諦めた)

今まで私はホストPCでLaravelコードをいじいじ→git push→ゲスト(VM)でgit pullという超絶面倒な方法を取っていた。

その為、そんなに機能を作っていないのにcommit数が1000を超えている。

今までもちょっと面倒だなぁと思ってたんだけど、今回の2週間、共有フォルダを利用して、もう共有フォルダの便利さを知ってしまった。

共有フォルダでLaravelフォルダを共有してしまえば、もうgitがいらなくなる。草を生やすためにも、セーブという意味合いでも使うけど。

そんで、VirtualBoxの場合普通「設定」→「共有フォルダ」でやればVM側の「/media/」に問題なく作れるらしいんだけど、私はAlmaLinuxだからかダメだった。

これはどうやら、「Guest Additions」というのをインストールする必要があるみたい。

GuestAddtionsを入れる

まず、以下でパッケージの更新と、必要なものをインストールする。

sudo dnf -y update
sudo dnf -y install kernel-devel kernel-headers gcc gcc-c++
sudo dnf -y install bzip2

そしたらVMの「デバイス」→「Guest Addtions CD イメージの挿入」

そのあと

sudo mount -r /dev/cdrom /media
を打ち込む。

これは、/dev/cdrom、つまりGuest AdditionsのCDイメージを/mediaにマウントして使えるようにする作業みたい。
-rオプションは「読み取り専用でマウントする」という意味。

これが出来たら、

cd /media
sudo ./VBoxLinuxAdditions.run

してインストール。

インストールし終わったら

cd ../
sudo umount /media

でアンマウントし

sudo reboot

で再起動

そしたらVMの共有フォルダ設定で

こんな感じで共有フォルダしたいホストPCのパスとフォルダ名、自動マウントと永続化するにチェックを入れる。

すると

/mediaにsf_フォルダ名でフォルダが出来ているはず。

でも、見てもらえばわかる通り権限的に触れなくなっているので

sudo gpasswd –add {ユーザ名} vboxsf

で好きなユーザーをvboxsfグループに入れる。
そして、ssh接続中ならsshを再接続。

試しにホストPCの方で以下みたいなフォルダとファイルを入れてみる

lsコマンドで見てみると

いいね！　出来てる！

PhpStormを使う

まず、PhpStormってなんやねんって感じなんだけど、PhpStormはIDE(統合開発環境)のこと。

今まで私はVSCodeという汎用的で無料なやつを使っていたんだけど、今回の2週間でPhpStormを利用したら滅茶苦茶便利だったので、こっちに移りたいと思う。

具体的に何が便利だったかって言われると……

コードの警告機能
PHPDoc自動生成機能
ER図自動生成機能
タイポ発見機能
コード整形
Git操作

とかかなぁ。

他にもいろいろあったと思うんだけど、とにかく便利だった。
なんか、そんな細かいところもやってくれるんすね！　みたいな。痒い所に手が届くIDE。

しかし、このPhpStorm、高い。

1年3万越えはちょっと……って感じ。

でも、30日の試用期間があるし、教育目的であれば学生は無料で使えるので、そこら辺をフルに活用していく。

ということで、それに全力で頼っていく。

PhpStormのインストール

まず、JetBrains Toolbox Appというのをダウンロード＆インストールする。
これは、IDEを管理するツール。IDEはプログラム関連を管理するツールで、これはIDEを管理するツール……もう、わけわかんないね。

このTookbox AppからPhpStormをインストール

私は外のWifiを使っていたせいか、恐らくポートの制限が掛かっていてインストールできなかったので、ブラウザからスタンドアロンをダウンロード＆インストールした。

しっかりスタンドアロン製でもToolboxは反応するので安心してほしい。

初期設定

色々設定していく。

まず、plugin→検索「Japanese」で以下の日本語パックをインストールする。

そんでリスタートしたら……

日本語になってるね！

それに加えて私は

.env files support
Alpine.js Support

を入れた

次に「カスタマイズ→すべての設定→エディタ→コードスタイル→PHP→選択して設定」でPSR12を指定。

「Ctrl + Alt + L」でフォーマット、コードの整形をしてくれるんだけどその時のルール設定になる。
後、気になる人はフォントを変えて完了かな？

PhpStormと新規Laravelプロジェクト

試しにPhpStormを使ってみようと思う。

バックアップをとる

VMはスナップショットでバックアップを取れるので、丸々とっとこう。

PHPのバージョンを上げて最新のLaravelをインストールする

Laravel10はPHPバージョン8.1以上に対応しているので、PHPのバージョンを上げる。

因みに現在は8.0.30

Laravel10のプロジェクトを使いたいので、PHPのバージョンを8.0から8.1以降にしたい。

dnf module list php
sudo dnf module reset php
sudo dnf module -y enable php:8.1
sudo dnf module -y install php:8.1/common
php -v

でPHPを8.1にして、

composer create-project laravel/laravel {プロジェクト名}

でLaravelをインストールすることで

10.30.0のLaravelをインストールできた。

これをgithubにprivateでpushして完了。

Breezeをインストールする

Laravelに認証パッケージのBreezeをインストールする。

昔は何となくやってたんだけど、ここらへんも理解しながら進めたい。
あと、共有フォルダを使うとたぶん壁があるんだよね。

まず、
php artisan migrate
でマイグレートし、
composer require laravel/breeze –dev
でcomposerからインストールするんだけど……composerがあまり理解できていないことに気づいたので、そこからやる。

Composerについて理解する

正直、今までよくわかんないままComposerをインストールして
composer install
とかでパッケージのインストールを行ってたわけなんだけど、そこらへんの理解をちょっとちゃんとしたいなぁと思って。

Composer関連はこちらがわかりやすかった(広告えぐいけど)。

Composer3つのファイル

Composerで大事になってくるファイルは以下の3つ。

composer.phar
composer.json
composer.lock

また、大事になってくるコマンドは以下の3つ

composer install
composer update
composer require

それぞれ見ていく。

composer.phar

こいつはcomposerの実行ファイル。

pharというのはPHP Archiveの略らしく、PHPのアプリケーションを1つのファイルに纏めて配布できる便利拡張子みたい。ドキュメントはこちら。

実際にcomposer.pharを覗いてみるとちゃんとPHPで書かれている。

本来はこれを

php {composer.pharがあるパス} install

のようにすることでcomposerが使えるんだけど、私達はだいたい

composer install

で使ってるよね。

これにはいわゆるパスを通すという環境変数の設定と、シバン(shebang)という#!から始まる最初の1行を利用しているからできることなんだよね。

環境変数の設定(パスを通すということ)

ここら辺は何となくわかるっちゃわかるんだけど、何となくだから明確にしていく。

先述の通り、普通のパスを通したcomposerは

composer install

のように使うわけだけど、これはパスが通ってるから。

パスを通すっていうのは、プログラム名だけで実行できるようにすること。ここら辺のソースはこちら。

さっき言った通り、本当の本当は

php {composer.pharがあるパス} install

で使うわけだけど、この相対パスか絶対パスを一々打つのは面倒だから、プログラム名だけで使えるようにさせてね！　っていうのがパスを通す行為。

じゃあ、どうやってパスを通すかって言うと、私のAlmaLinuxの場合は
/etc/environment
に記述することでパスを通せる。

例えば私のenvironmentを見てみると

PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin”

のように「パスを通したい場所:パスを通したい場所:」のようにコロン:で区切られて予め何個か登録されている。

私の場合はこの中の「usr/local/bin」という記述が今回のcomposerに関わっていて、usr/local/bin/の階層にcomposerとういファイルがあるので、わざわざ「usr/local/bin/composer」とやらなくてもcomposerが使える。

実際、composerの公式ページに行くと、

mv composer.phar /usr/local/bin/composer

でグローバルにインストールするとあるので、恐らく昔の私はこの方法でcomposerをインストールしたんだろうなぁ。

シバン(shebang)を軽く理解する

パスを通しただけじゃ、php composer.pharのphpが要らなくなった理由が解決しないよね。

これはシバンという「#!」から始まる特殊な1行を利用しているから。
ここら辺のソースはこちら。

実際にcomposer.pharを覗いてみると

この画像の通り、一番最初に#!から始まるシバンが存在する。
これでPHPコマンドを勝手につけてくれるようにしていたってことだね。

これを調べてるうちに湧き出た疑問が結構あるのでそこらへんも見てみる。

binフォルダとは

binフォルダって結構みるし、なんかどこにでもあるけどなんなんだろう。ってところで調べて見る。
ここら辺のソースはこちら。

binはバイナリの略。バイナリって0と1の2進数という意味だよね。
そして、このbinフォルダには実行ファイルを入れるのが慣習らしい。

だから、composerの実行ファイルはbinフォルダに入れるし、パスも事前に通ってるんだね。

拡張子とは

今回のcomposerのインストール方法を調べてるうちに、拡張子がよくわからなくなったので、調べる。

当たり前なところではあるんだけど、拡張子は「ファイルの種類を判別する為に末尾の.の後に付ける文字列」のこと。

具体的な疑問は「mv composer.phar /usr/local/bin/composer」でcomposer.pharのphar拡張子を取っちゃってるけど、問題ないの？　ってところ。

結論から言えば問題ない。

なぜかというと、Windowsと違ってLinuxのファイルが実行可能か否かはパーミッションで決まるから。

Windowsは.exeとか.batとかが付いた拡張子じゃないと実行出来ないようになっている。しかし、Linuxでは関係なくそのファイルを呼び出すだけで実行が出来てしまう。

だから、今回composer.pharのpharを取った状態でも実行が出来たということらしい。

composer.jsonとcomposer.lockとコマンドたち

かなり話が脱線したんだけど、composer.jsonとcomposer.lockの話にいきたい。
ここらへんでわかりやすかったのはこちら。

めっちゃくっちゃ誤解を恐れずに簡潔に纏めると

composer.jsonが手動で追加したパッケージ一覧
composer.lockがパッケージの依存関係も含めた追加削除履歴

そして、この2つのファイルはLaravelをインストールすると最初からついてるけど、本来はどちらも最初から無い……当たり前か。

まず、このcomposer.jsonは
composer init
というコマンドから初めて生成される。

composer init時にインストールしたいパッケージやバージョンを指定することで、それらが書いてあるcomposer.jsonファイルが生成されるという感じ。

composer.jsonがある上で
composer install
をするとこのcomposer.jsonを元に依存関係を解決しパッケージをインストールしてくれる。
そして、その時にcomposer.lockというファイルが初めて生成される。
このcomposer.lockにcomposer.jsonにあるパッケージをインストールした日付とか、その時に行った依存関係のインストール情報とかが残っていくという感じ。

以降、composer.lockがある限りは
composer install
をしてもcomposer.jsonを元にインストールはされず、composer.lockの履歴の最新の物を元にインストールされる。

環境を共有する際は、composer.jsonとcomposer.lockを共有をしてあげればおｋ。

頭入んないかもだけど、composerの理想の使い方を。

composer initでcomposer.jsonファイルの生成
composer.jsonファイルにインストールしたいパッケージを追加
この時はcomposer init時の対話形式で追加してもいいし、直接ファイルを弄ってもいいし、composer requireで追加してもいい。
comoser installでインストール
composer.lockはパッケージの追加削除履歴なので、ここまでは生成されていない。
composer.lockが無い場合はcomposer.jsonを元に依存関係を解決しインストールしてくれる。
composer installが終わるとcomposer.lockが生成
初めて変更があったので、履歴を残すためにcomposer.lockを生成。
生成されたcomposer.lockとcomposer.jsonを他人に配布
composer.lockがある場合、composerはその一番新しい履歴をもとにインストールするのでcomposer.lockも配布する。
他人がcomposer install
composer.lockを元に同じ状況を再現してくれる。
composer.jsonも何かオートローダとか色々してくれてる。
もし、パッケージをアップデートしたいときはcomposer update
何も指定しなければcomposer.jsonを元に全てのパッケージを最新の物に。
composer update {パッケージ:バージョン}みたいな感じで指定もできる。
もし、composer.lockが生成されている状態で新しいパッケージを追加したかったり削除したければcomposer requireかcomposer remove
requireやremoveはcomposer.jsonもcomposer.lockもどちらも更新してくれるので、これで変更を加える。

という感じ。

composerのdevとは

今回、Breezeをインストールするときに
composer require laravel/breeze –dev
のように–devを付けるけどこれは何なのか。

これはdevelopのdevで、開発時と本番環境時でインストールを分けたいときに付けるやつ。実際にcomposer.jsonを見てみると。

"require": {
   "php": "^8.1",
   "guzzlehttp/guzzle": "^7.2",
   "laravel/framework": "^10.10",
   "laravel/sanctum": "^3.2",
   "laravel/tinker": "^2.8"
},
"require-dev": {
   "fakerphp/faker": "^1.9.1",
   "laravel/pint": "^1.0",
   "laravel/sail": "^1.18",
   "mockery/mockery": "^1.4.4",
   "nunomaduro/collision": "^7.0",
   "phpunit/phpunit": "^10.1",
   "spatie/laravel-ignition": "^2.0"
}

phpとかlaravelとかの本番環境でも必要なものはrequireに入っており、fakerとかphpunitとかの本番環境でいらないものはrequire-devに入っている。

もし、本番環境でcomposer installをするときは
composer install –no-dev
でインストールすることで、devに入っているパッケージをインストールせずに済むという感じ。

って私、前のデプロイ時–no-devでインストールしてない気がする……

理解した上でBreezeをインストールする

composerをある程度理解した上で、Breezeをインストールする。

改めて、.envのDBの設定とかを終わらせた上で

php artisan migrate

でマイグレートし、

composer require laravel/breeze –dev

でインストール。
インストール後に

php artisan breeze:install
を実行

色々細かい設定を聞かれる。私は以下のようにした。

というか、こんなのあったっけ？　私がLaravel9の時にやんなかっただけ？
ダークモードのサポート有無を聞いてくれるのはマジでありがたい。

と思ったらエラー出た。そうだよね。

シンボリックリンクエラーと闘う

はい、出ました。シンボリックリンクエラー。

検索で引っかかるように以下にエラー文全部置いとく。

npm notice
npm notice New major version of npm available! 8.19.4 -> 10.2.2
npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.2.2
npm notice Run npm install -g npm@10.2.2 to update!
npm notice
npm ERR! code EPERM
npm ERR! syscall symlink
npm ERR! path ../autoprefixer/bin/autoprefixer
npm ERR! dest /media/sf_MusicArticle/MusicArticle/node_modules/.bin/autoprefixer
npm ERR! errno -1
npm ERR! Error: EPERM: operation not permitted, symlink '../autoprefixer/bin/autoprefixer' -> '/media/sf_MusicArticle/MusicArticle/node_modules/.bin/autoprefixer'
npm ERR!  [Error: EPERM: operation not permitted, symlink '../autoprefixer/bin/autoprefixer' -> '/media/sf_MusicArticle/MusicArticle/node_modules/.bin/autoprefixer'] {
npm ERR!   errno: -1,
npm ERR!   code: 'EPERM',
npm ERR!   syscall: 'symlink',
npm ERR!   path: '../autoprefixer/bin/autoprefixer',
npm ERR!   dest: '/media/sf_MusicArticle/MusicArticle/node_modules/.bin/autoprefixer'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

これ、2週間の際にも遭遇したエラーで、どうやらWindowsの場合、共有フォルダ内にシンボリックリンクを張ろうとすると権限がなくてエラーになるみたい。

これは、Windows側の問題、というかWindowsの仕組み上、Windowsのルート権限でないとシンボリックリンクを張れない仕組みなので、VM側でどうにか出来る事じゃない。
つまり、シンボリックリンクを張らない仕組みをVM側でどうにか作るか、Windowsのルート権限の設定をどうにかするしかないという感じ。

前に調べて見た感じWindowsの管理者権限でVMを起動するとか、なんか色々解決方法は出てきたんだけど、私の場合は解決しなかった。

だから、やれることとしては

シンボリックリンクの権限設定を弄る(Windows proのみ)
共有フォルダのシンボリックリンクを使わない仕組みを作る
Windows側でLaravelを弄る

2週間の頃の私は2番の方法で解決したんだけど、これWindows側で弄れば解決なのではと、ふと思ってしまった。

Windows側でLaravelを弄ってみる

つまり、共有フォルダでWindows側にLaravelフォルダを共有しているので、Windows側の管理者権限で起動したcmdで

php artisan breeze:install
を打ち込んでみる……

うーん。なんかいけた。

まじか。
私、2週間の内の1日をこの解決に使ったといっても過言じゃないのに……

視野が狭かったね。

因みに、npmとかstorageにシンボリックリンク張る時とかはwindowsでやれってことになるねこれ。

少しそこは面倒だけど、恐らく問題なく使えるので、いいか。
※バグだらけでした

最後にmigrateしとく

breezeのインストールが終わったら

php artisan migrate
でマイグレートを一応しとく。ただそれだけ。

ApacheにLaravelプロジェクトを認識してもらう

ここらへんのバーチャルホストとかもよくわからずに使っていたので、ここで理解したいかなぁ。

とりあえず使えるようにするには

今回はVMの環境なので、以下の手順でApacheに認識してもらう。

Linux側のバーチャルホストの設定
ホスト側のhost(DNSエミュレート)の設定
systemctl restart httpd
systemctl restart PHP-FPM
なぜかこれをしないと「’Primary script unknown’」と「File not found.」というエラーに

こんな感じ。

バーチャルホストとDNSの設定は過去の私の記事を参照。

restart httpdはApacheの設定を再読み込みさせるためのものなんだけど、私の環境の場合はPHP-FPMという謎のシステム再起動も必要だった。

分からない事が何個かあるので、調べてみる。

Apacheの.confファイルは何？

例えば、今回の場合Linux側のバーチャルホストの設定を/etc/httpd/conf.d/test_app.confで以下のようにしたんだけど、そもそもこの.confファイルって何？

<VirtualHost *:80>
    DocumentRoot /media/sf_MusicArticle/MusicArticle/public
    ServerName music.test
    <Directory /media/sf_MusicArticle/MusicArticle/public>
        Require ip 192.168
        AllowOverride All
    </Directory>
</VirtualHost>

結論から言えば.confファイルはApacheの設定(configuration)ファイル……まあそうだよね。

この.confファイルはApacheの設定ファイルで、メインの設定ファイルというのが
/etc/httpd/conf/httpd.conf

にある。

このhttpd.confが一応メインファイル、軽くでいいので中身とそのコメントを見ておくといいかも。

このメインファイルの下の方に

IncludeOptional conf.d/*.conf

という記述があり、この記述のおかげでconf.dフォルダの.conf拡張子ファイルを任意の追加設定ファイルとして認識してくれている感じ。

だから、もし設定を追加したいときはconf/httpd.confに追加するのではなく、conf.d/の中で.confファイルを作ってやるのがいいみたい。

設定ファイルで何を記述しているのか

Apacheの設定ファイルはディレクティブというもので設定している。

例えば、さっきの例だと「VirtualHost」「DocumentRoot」「ServerName」「Directory」「Require」「AllowOverride」の6個がディレクティブになる。

詳しい説明は公式ドキュメントを見るといいと思う。めっちゃディレクティブの種類ある。

とりあえず、今回使った6個のディレクティブだけ説明してみる。

<VirtualHost>ディレクティブ

公式ドキュメント

これはApacheのバーチャルホストを設定するディレクティブ。
もし、条件に当てはまればこの<VirtualHost>から</VirtualHost>のタグ内の処理を行うみたいな感じ。

今回の私の場合
<VirtualHost *:80>
なので、*:80という条件。
これは、「リクエスト先のIPアドレスはなんでもいいけど、ポート番号が80番の場合True」みたいな意味。もし、サーバーが複数のローカルIPを持っていて、IPによって条件を変えたい場合は*じゃなくて任意のIPを指定する。

なので、80番ポートのアクセスは全てこのVitualHostタグ内の処理を通っている。

DocumentRootディレクティブ

公式ドキュメント

DocumentRootはApacheが使うディレクトリを指定してあげるディレクティブ。

Laravelの場合、publicフォルダを指定してあげればおｋ。
つまり、publicフォルダ内のフォルダしかApacheはやり取りできないということ。

過去の私の記事を見てもらえばわかる通り、Laravelはindex.phpというファイルがエントリポイントになっていて、そのファイルはpublicにあるので問題ないってわけか。

また、storageとかもシンボリックリンクを使ってpublicと繋いでいるので問題ないんだね。

ServerNameディレクティブ

公式ドキュメント

今回利用したServerNameの利用方法は、複数VirtualHostを設定した時にどのホスト名に対してのリクエストなのかを判別する為の利用方法。

VirtualHostが複数あっても、
ServerName music.test
と

ServerName programming.test

と内部でServerNameを分けてあげることで、どこへのアクセスかを判別出来るようにするみたいな使い方。

<Directory>ディレクティブ

公式ドキュメント

<DIrectroy>は<VirtualHost>ディレクティブと同じように、「指定したディレクトリにアクセスする場合のみ、<Directory>から</Directory>のディレクティブを適用する」というディレクティブ。

なので、今回は「/media/sf_MusicArticle/MusicArticle/public」にアクセスする場合。
Require ip 192.168
AllowOverride All

のディレクティブを適用するよ。という感じ。

これ、わざわざディレクトリ指定しなくても

<VirtualHost *:80>
    DocumentRoot /media/sf_MusicArticle/MusicArticle/public
    ServerName music.test
    Require ip 192.168
    AllowOverride All
</VirtualHost>

みたいな感じでよくない？　
って思ったんだけど、AllowOverrideというディレクティブが<Directory>ディレクティブ内でないと有効にならないみたい。
また、Requireも<Directory>ディレクティブ内で使うのが普通みたいね。

Requireディレクティブ

公式ドキュメント

Require [条件]みたいな感じでアクセス制限をかけれる。

今回はipが192.168から始まる人だけ、<Directory>で指定したディレクトリにアクセスできるという感じ。ローカル環境なら正直つけなくていいかなぁとも思うけど、付けても動くので、付けておく。

AllowOverrideディレクティブ

公式ドキュメント

これは<Directory>ディレクティブ内で有効になるディレクティブ。

内容は、指定したDirectory内に.htaccessファイルがあった場合、そのディレクティブを適用するかというディレクティブ。

今回は「AllowOverride All」に設定しているので、.htaccessがあったらその中にあるディレクティブを適用する……っといっても.htaccessでディレクティブを追加で適用できることを知らなかったよ。

Laravelでは、publicフォルダ内に.htaccessファイルがあって、この.htaccessファイルのディレクティブ設定がリクエストをindex.phpに誘ってくれているんだね。

public内の.htaccessファイルを見て解説した方が本当はいいんだろうけど、むずそうだったので今回はパス。

とりあえずこんな感じか。

何となくわかる→まぁわかるくらいにはなった気がする。

PHP-FPM

今回なぜかこのPHP-FPMという謎のシステムを再起動しないとApacheが正常に動いてくれなかったんだよね。PHP-FPMがなんなのか、何故再起動が必要なのかがわからないので、まずPHP-FPMを軽く理解する。

PHP-FPMはPHPにおけるFastCGIである

公式ドキュメント

PHP-FPMはPHPにおけるFastCGIらしい。
よくわからんね。

CGI(Common Gateway Interface)とは

今回の文脈でのCGIは、「Webサーバー側で動的にPHPを動作させ、Webページを生成する仕組み」のこと。

もっと広義にすると、「Webブラウザからの要求に動的にWebサーバー側で答える仕組み」のことみたい。

このCGIが開発される前は、静的なWebページしか提供できなかったんだとか。
つまり、ブラウザからの要求に応じてWebページを作成できなくて、既に出来たWebページしか提供できなかったという感じ。

これって、Apache→Laravel(index.php)という順でリクエストが渡ってるんじゃなく、Apache→CGI→Laravel(index.php)という順でリクエストが渡っているということだよね。

FastCGIとは

FastCGIは、リクエスト事にプロセスの起動・終了をしていたCGIとは違い、一定の期間であればプロセスを使いまわす仕組みを入れたものを言うらしい。

従来のCGIの、プロセスの起動・終了が結構スピード的にネックだったんだけど、それが緩和されて早くなるんだとか。

何故PHP-FPMを使うのか

ここら辺はあまり関係ないと思うので、軽く。

こちらのサイトによると、Apacheにはmod_phpというモジュールがあって、それでPHPを動かすことはできる。でも、CentOS 8ではなんやかんやあって、mod_phpが使えなくなったので、PHP-FPMを使ってるみたい。

何故再起動が必要だったのか

一応ここが疑問点だったので。

恐らくだけど、PHPのバージョンを上げたからかなぁと思っている。

今までの説明通り、PHP-FPMはApacheがPHPと連携をする為に必須の物。
そして、PHPのバージョンを上げるときにPHP-FPMとかのPHP関連もバージョンが上がるんだよね。

で、PHP-FPMのバージョンは上げたけど、常駐しているPHP-FPMは更新していないところがあったので、整合性が取れないところがあってエラー出てたのかな。

とりあえず、動いたのでおｋ。

再現していく

なんか、超無駄な仕事なのではないかという疑問が無くはないんだけど、1週間もかからんだろうと踏んで、新しいプロジェクトで既存のプロジェクトの再現をする。

といっても、既にコードとか諸々あってコピーできるのでそんなに大変な作業ではない。

新しくする理由は以下の通り

リファクタリングをしたい
Laravel10にしたい
作り直すことで、理解を深めたい
コメントを増やしたい(PHPDocも)
テストを増やしたい

いや。マジで意味ないかも。どうしよ。これ、既存の物をリファクタリングすれば良くないか？

うーん。意味がないのも経験の内かなと思い、そんなに時間もかからないと思うので、とりあえずやってみる。

進め方は以下の通り

既存のマイグレーションファイルのコピー
viewの作成
ロジックの作成
それに伴うテストの作成
以下2~4の繰り返し

という感じ。

既存システムからの変更点

Telescopeの追加
phpMyAdminの追加
ユーザーIDの仕組み変更
ついでに、自己紹介・ヘッダ・外部リンクを追加
画像などの保存方法の変更
論理削除の実装を検討

PhpStormにGitHub Copilotを入れる

これ、コーディングしてて思ったんだけど、GitHub Copilot欲しいな。

勿論頼りきる訳ではないんだけど、確実に作業効率は上がると思うので、PhpStormに入れてみる。

「ファイル→設定→プラグイン→Marketplace」でGitHub Copilotをインストール。

ほんの少し前は「Tabnine AIが超便利！」って言われてたのに、もうダウンロード数で約2倍の差があるんだね。とそれっぽいことも言ってみる。

PhpStormを再起動すると以下のような画面になるので、

確か、GitHub Proじゃないと使えないんだけど、学生なら無料でProになれるのでおすすめ。

素晴らしいね、めっちゃ理想のもの提案してくれる。

論理削除について

論理削除という存在を知ったので、必要かどうかを考える。

論理削除というのは、新たにdeleted_atというカラムを追加し、削除時にdeleted_atに日付を入れることで疑似的な削除を実現する方法。実際にはDB上から削除しない。

つまり、

deleted_atがnull = 削除されていない
deleted_atに日付がある = 削除されている

という感じでプログラミング上で扱う。

対の言葉として、物理削除というのがある。
これは、標準的な方法で削除時にDBから削除してしまうという方法。

論理削除のメリットとしては

データの誤削除や復旧に対応できる
データを保持することで、退会ユーザーのデータ分析が可能(プライバシー的にどうかはわからん)

デメリットとしては

DBの圧迫
扱いづらさUP

恐らくこんな感じ。

DBは圧迫を感じるレベルまで達していないので、そこは一旦置いておく。
問題なのは、論理削除にすることによる扱いづらさ。

例えば、ユーザーを論理削除で実装したとして「ユーザーを削除したとき、それに紐づく記事やいいねはどうするの？」とか、「間違えて論理削除している記事も見える設定にしちゃった！」とかあるよね、恐らく。

マジで扱いにくくなる。
下書き機能の時点でややっこいのに、更に複雑になるんだよね。

果たして実装するべきなのだろうか。

思う事

記事を論理削除で保存するとして、プライバシー的なところが気になる
「間違えてIDとPWを記事に載せちゃった！→削除しよう！→物理削除」の方がプライバシー的にも、わかりやすさ的にも良いよね。
もし論理削除を実装した場合、こういう事態が起きた時に、「ユーザーが運営に報告→一々手動でDBから消す」という手間が増えるんだよね。
このサイトは今のところ個人で長く運営したいので、手間が増える論理削除はあまり良くないかもしれない。
別の方法を考える
やはり、論理削除は個人でやるにはコスパが悪いと思うので、X(Twitter)の鍵垢みたいなものを実装できないだろうか。
そうすれば、ユーザーもわざわざ削除という手段を選ぶ必要が無くなるんじゃないかなぁ。

論理削除の結論

やっぱりどうしてもコスパがあまり良くないと感じるので、実装しない。
その代わり、ユーザーにX(Twitter)の鍵垢みたいな物を将来的に実装することを考える。

定数を扱う

記事下書きの保存時・記事編集時・記事の保存時ってタイトルの文字数制限とか全く同じ数値を使うよね。全く同じ数値を使うなら、一貫性を持たすためにも定数を保管する場所を作ってそこから値を取得するという方法を取りたい。

通常はconfigフォルダにconst.phpというファイルを作ってそこに定数を追加していくみたい。

一応他にも

laravel-enumという外部パッケージを使う
PHPのEnumを使う
モデルに記述する

等々の方法が存在する。
でも、一番シンプルなのはこのconst.phpの方法っぽいので、今回はこの方法でやってみる。

const.phpで定数を扱う

大規模なアプリケーションになるとconst.phpで管理するのは難しかったりすると思うんだけど、このWebアプリケーションは小規模〜中規模だと思うので一回この方法でやる。

config/const.phpのようにconst.phpというファイルを作って、今回の私の場合は以下みたいに定義してみる。

<?php
/*
|--------------------------------------------------------------------------
| オリジナルの定数置き場
|--------------------------------------------------------------------------
*/
return [
   /*
|--------------------------------------------------------------------------
| ユーザー関連の定数
|--------------------------------------------------------------------------
|
|
|
*/
   'user' => [
       'nameMaxLength' => 15,  // 一意の名前の最大文字数。Twitterを参考
       'name_displayMaxLength' => 20,  // ニックネームの最大文字数。過去のTwitterを参考
       'introduction_textMaxLength' => 190,  // 自己紹介文の最大文字数。QiitaとTwitterを参考
   ],
];

こんな感じで、定数を追加する。

使う時は

config(‘const.user.nameMaxLength’)

みたいな感じで使える。

ちょっと長くなっちゃうのが気になるんだけど、しょうがないね。

AlmaLinux(CentOS)にphpMyAdminを入れる

こちらも、使ってみたら便利だったので入れてみる。

phpMyAdminとは？

Webブラウザ上でMySQLを視覚化してくれるソフトウェア。GUI操作によるDBの編集が可能。
15年以上の歴史があって、日本語化もされている。

公式ページ

これを、RemiやEPELリポジトリからdnfで入れていく。

パッケージ管理システムについて

今まで、dnf(yum)とかで言われるがままにインストールしてきたわけだけど、しっかりは理解できてないよね。ってところで、簡単に説明できるくらいは理解したい。

dnf(yum)について

dnf(yum)はRed Hat系Linuxディストリビューションで利用されるパッケージ管理ツールのこと。

yumはpython2で書かれており、dnfはpython3で書かれているらしい。(参考)

そのため、昔はyumが使われていたけど、今はdnfが使われている。
慣習的にyumというコマンドは使えるが、裏ではdnfが動いている。

ここらへんの公式ドキュメントはこちら。

サードパーティリポジトリについて

よく、RemiリポジトリとかEPELリポジトリとかいうけど、なんだあれ。

簡単に言うと、RemiやEPELリポジトリはサードパーティのリポジトリ。
つまり、公式が提供しているものではない。

だから、自己責任で利用しなきゃいけない。

Remiリポジトリ

ドキュメントはこちら。

Remiリポジトリはその名の通り、Remiさん個人が提供するリポジトリ。

主に、最新のPHPやその関連パッケージを扱っている。

EPELリポジトリ

ドキュメントはこちら。

EPELリポジトリは、Fedora Projectというコミュニティが管理しているリポジトリ。

Remiリポジトリとの比較として、組織というところが大きく違うところ？
私個人の考えとして、個人より組織の方が安定性があるのかなぁと思うので、可能な限りEPELリポジトリを使うのがいいのかな。

リポジトリからのダウンロードは違法ダウンロードにならないか

Q.リポジトリからのダウンロードは違法ダウンロードにならないか
A.サードパーティ製リポジトリは保証がないよね

正直、プログラミング系ツールで違法ダウンロードとか気にする人あんまいないのかなぁと思うけど、大事なので。

結論から言えば、リポジトリが提供しているソフトウェアが「オープンソースor許可を与えている」ならおｋ。それ以外ならアウト。

でも、RemiやEPELリポジトリは有名どころなので大丈夫だとは思うけどね。
どちらにしろ、自己責任でってやつ。

phpMyAdminを入れる

私の場合、EPELリポジトリを使うので、EPELリポジトリをこの方法で使えるようにする。OSやバージョンによって使えるまでがかなり変わるっぽいので、リンク先を参考に。

使えるようになったら

sudo dnf install phpMyAdmin

でインストール。

しっかり、Repoがepelになってるので、EPELを利用したインストールを行っていることがわかる。

インストールが完了したら、
/etc/httpd/conf.d/phpMyAdmin.conf
のように、phpMyAdmin用のApache設定ファイルが出来ているので、私の場合はバーチャルホストの設定とかをする。

バーチャルホストの場合、

ServerName {example.xxx}

とかでServerNameとかwindows側でもバーチャルホストの設定をしておいて、「example.xxx/phpMyAdmin」でアクセスできる。

ここらへんは、Apacheの設定ファイルをある程度理解していたのですんなりいけた。

ユーザ名とパスワードはMySQLで設定したものを入れてログイン出来たらおｋ！

共有フォルダの際「ERR_CONTENT_LENGTH_MISMATCH」エラーに遭遇する

なんかわからんけど、こちらの方法を試したら解決した。

sudo vi /etc/httpd/conf/httpd.conf
で設定開いて

EnableSendfile off
を設定。

うーん。わからん。

共有フォルダを諦める

うーん。

共有フォルダってコミット数減るし、めっちゃ便利なんだけど、その代わり共有フォルダ依存の互換性バグみたいなのも多くて、正直つらい。
npm installらへんもバグるし、シンボリックリンクも面倒だし、ERR_CONTENT_LENGTH_MISMATCHも出るし。

だから、ここまでやっといてあれなんだけど、共有フォルダを諦めて、元のプロジェクトををリファクタリングする方針にしようと思う。

この環境構築で色々学ぶことはできたけど、やっぱり少し無駄ではあったかなという感想。
反省。

最後にPhpStormを初音ミク＆重音テト色にする

結論から言えば、今回の作業は殆ど進捗に繋がっていない。反省。

モチベーションみたいなところも下がり気味なので、とりあえずPhpStormの見た目をミク＆テト色にしようと思う。

PhpStormとVSCodeの比較

こっちがPhpStormで

こっちがVSCode

私は、VSCodeのカスタマイズしたこの見た目が好きだから、PhpStormもこんな感じにしたい。

やり方

‘Ctrl+Alt+S’でPhpStormの設定を出して、「エディター→カラースキームの切り替え」

ここで、とりあえず理想に一番近いカラースキームを見つける。

個人的に’Monokai’というのが、コントラスト的に良さげだったので、これをも元にカスタムしていく。

理想に近いカラースキームを見つけたら、「歯車マーク→複製→名前を付ける」

複製できたら、「カラースキームの切り替え→PHP→好きな要素→次の値を継承をオフ」でお好みの色を設定する。

また、変えたい要素をクリックすれば、そこから変えることもできる。

とりあえず、軽く設定した。

これで頑張る。

おやすみなさい。