環境 AWSのEC2インスタンス上に、ApacheとPHPをインストールし作業しました。 また、curlを用いて、コマンドラインからHTTPリクエストをサーバーに送りました。 HTTPリクエストにはGETやらPOSTやらPUT、DELETEといったメソッドがあり、 無知すぎてこれらを判別するのにかなり苦労しまして、今回ここにまとめておこうと思い立ったわけです。 はじめに試した方法（失敗） はじめに、 $_GET と $_POST を使ってHTTPリクエストメソッドを判別できないか、試してみました。 $_GET と $_POSTはそれぞれ、HTTPリクエストメソッドのGETとPOSTによって渡されたパラメータを返します。 例えば、以下のようなコマンドでGETとPOSTをリクエストし、成功したとします。 このとき、$_GETと＄＿POSTからは"apple"が返されます。 [GETするコマンド] curl (サーバーのURL)/?name=apple ---------------- [POSTするコマンド] curl -d {"name": "apple"} (サーバーのURL) index.php $get_param = $_GET["name"]; //出力: $get_para => "apple" ---------------- $post_param = $_POST["name"]; //出力: $post_post => "apple" この方法は、HTTPリクエスト時にパラメータが指定されていなければ、 受けたリクエストメソッドがGETなのかPOSTなのかを判別することができません。 さらに、$_PUTとか$_DELETEは残念ながら存在していないようですので、GETとPOST以外のリクエストメソッドは当然判別することができません。 私はこいつらがメジャーなせいで、かなり悩まされました。 （そもそも、もしや世の中ではパラメータを受け取れることが最重要で、それが何のリクエストメソッドかは二の次なのか．．．？） 追記：そもそも、HTTPリクエストメソッドを判別する方法は後述の$_SERVERが適当であり、 $_GETや$_POSTはパラメータを受け取るために使われるものになります。 （本記事に@tadsan様よりコメントを頂きました。詳細についてはコメントの方をご参照ください。） HTTPリクエストメソッドを判別する方法 ①で悩み続けた私が、苦行の果てに発見した手法が$_SERVER['REQUEST_METHOD']を用いるもの。 まず、$_SERVERというのは、 サーバー情報および実行時の環境情報を取得するものだそうです。 そしてこの$_SERVERは、キーはめちゃくちゃたくさんある連想配列なのですが、 キーの中に先述のREQUSET_METHODがあり、指定するとHTTPリクエストメソッド名を返してくれます。 以下、例を挙げます。 [GETするコマンド] curl (サーバーのURL) ---------------- [DELETEするコマンド] curl -X DELETE (サーバーのURL) index.php $method = $_SERVER["REQUEST_METHOD"]; //出力: $method => "GET" ---------------- $method = $_SERVER["REQUEST_METHOD"]; //出力: $method => "DELETE" 以上のように、GETやPOSTでパラメータを指定していなくても、 HTTPリクエストメソッドを判別することができます。 また、GETとPOST以外のリクエストメソッドの名前も返すことができるため、 PUTやDELETEなどのHTTPリクエストメソッドを判別することができます。 おわりに 今回は、PHPでHTTPリクエストメソッドを判別する方法についてまとめました。 それぞれのパラメータを取得する方法は他にもたくさんありましたが、 それらは調べればすぐに出てきましたので、今回は割愛いたしました。 Unity Student Planに加入する方法をまとめた記事が、ありがたいことに思ったよりもたくさん見られていて、驚き & 感謝です。 （ちょっと宣伝．．．?） それでは、最後まで読んでいただき、ありがとうございました！ また気が向いたら投稿します。('ω')ﾉｼ

はじめに MacOS内のPHPバージョンを7.3から7.4にあげる必要があったのですが、すんなりいかなかったので備忘録として残しておきます。 手順 1. 現在のPHPバージョン確認 まずは現在のPHPバージョンを確認します。 $ php -v PHP 7.3.11 (cli) (built: Jun 5 2020 23:50:40) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies 7.3ですね。 2. HomebrewにてPHP7.4のインストール Homebrewにて7.4をインストールします。 まずはHomebrewをアップデート $ brew update 7.4のインストール $ brew install php@7.4 Error: Permission denied @ apply2files - /usr/local/share/locale/cs/LC_MESSAGES/libidn2.mo Warning: Already linked: /usr/local/Cellar/libidn2/2.3.1 To relink, run: brew unlink libidn2 && brew link libidn2 残念。エラーです。 リンクが影響しているということなので言われた通りリンクを貼り直してみます $ brew unlink libidn2 Unlinking /usr/local/Cellar/libidn2/2.3.1... Error: Permission denied @ apply2files - /usr/local/share/locale/cs/LC_MESSAGES/libidn2.mo Permissionで怒られました。 権限変更してみます。 $ sudo chown -R $(whoami) /usr/local chown: /usr/local: Operation not permitted 失敗！ High Sierraから/usr/localの権限変更ができなくなったようです。 階層絞って再度やってみます。 $ sudo chown -R $(whoami) /usr/local うまくいったぽいので再チャレンジ $ brew unlink libidn2 && brew link libidn2 Unlinking /usr/local/Cellar/libidn2/2.3.1... 43 symlinks removed. Linking /usr/local/Cellar/libidn2/2.3.1... 51 symlinks created. できた これでようやくインストールできそうです。 $ brew install php@7.4 （中略） To enable PHP in Apache add the following to httpd.conf and restart Apache: LoadModule php7_module /usr/local/opt/php@7.4/lib/httpd/modules/libphp7.so <FilesMatch \.php$> SetHandler application/x-httpd-php </FilesMatch> Finally, check DirectoryIndex includes index.php DirectoryIndex index.php index.html The php.ini and php-fpm.ini file can be found in: /usr/local/etc/php/7.4/ php@7.4 is keg-only, which means it was not symlinked into /usr/local, because this is an alternate version of another formula. If you need to have php@7.4 first in your PATH, run: echo 'export PATH="/usr/local/opt/php@7.4/bin:$PATH"' >> ~/.zshrc echo 'export PATH="/usr/local/opt/php@7.4/sbin:$PATH"' >> ~/.zshrc For compilers to find php@7.4 you may need to set: export LDFLAGS="-L/usr/local/opt/php@7.4/lib" export CPPFLAGS="-I/usr/local/opt/php@7.4/include" To have launchd start php@7.4 now and restart at login: brew services start php@7.4 Or, if you don't want/need a background service you can just run: ようやくできました。 3. PHP7.4の適用 パスを通して $ echo 'export PATH="/usr/local/opt/php@7.4/bin:$PATH"' >> ~/.zshrc $ echo 'export PATH="/usr/local/opt/php@7.4/sbin:$PATH"' >> ~/.zshrc PHPをリスタートして $ brew services start php@7.4 変更を反映すれば $ source ~/.zshrc $ php -v PHP 7.4.21 (cli) (built: Jul 12 2021 11:52:30) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.21, Copyright (c), by Zend Technologies バージョンが7.4へと更新されました！ おわりに 一瞬でいけるかと考えてましたが思いの外時間かかりました。 誰かの助けになれば幸いです！ 参考

前提 LaravelのMVCモデルについて自分なりにまとめてみました！！ 間違っている部分やアドバイスいただけると嬉しいです。 (現時点：2020年7月27日） MVCの意味とは？ ・Model（モデル)：DBとのやりとりを行うところです。 ・View　(ビュー)：表示の担当を行うところです。（見た目を整える。HTML,CSS,Jsなど） ・Controller　(コントローラー)　：アプリ全体を統括する大黒柱的な存在です。（データをModelに渡したり、データーをViewに渡したりDBに保存してもらうなど） それぞれの頭3文字を取りMVCと言います。 私は上記の意味を理解してからLaravelでの開発にもスムーズに進むことが増えました！(エラーと葛藤している時間の方が長いですが。）笑 Laravelの勉強でも一番大切なのではと思うくらい重要だと個人的には思います。 ここからは一つずつ細かく解説していきます。 Model ・Modelは主にControllerで処理されたデータをデーターベースに格納する役割があります。 【Modelでできること】 ・データをDBに格納する ・DBからデータを引き出す ・DBのテーブルの関連付けが可能 View ・Viewは表示を担当するところでControllerで処理されたデータを元に、綺麗に見た目を整えて表示する役割があります。 Viewはロジック的なことはせず、ロジックは全てController,Modelに任せることが望ましいです。 【Viewでできること】 ・Controllerからデータを受け取る ・見た目を整える ・ヘッダーやフッターなどの使い回しができる Controller ・最後に一番重要なControllerです。Laravelのシステムを全て制御しているもので、データをModelに送信したり、フロントにデータを送信したりする役割があります。 【Controllerでできること】 ・データをModelに送信する ・データを受け取りフロントに送信する ・リクエストが来た際にどのViewを表示するか制御 まとめ 素のPHPだけで書くと重くエラーの原因も見つけにくいためLaravelのMVCモデルのファイルで分けることでエラーが起きた際も分かりやすいですし役割が明確なためコードが読みやすいのもありますね！！ 読んでくれた方々ありがとうございます！

はじめに CodeDeployでデプロイ自動化を実装しようとした時、エラーがいくつか出たため記録として残します。 ほぼ凡ミスのような感じですが、参考になれば幸いです。 条件 macOS: "11.2.3 Big Sur" php artisan -V # > Laravel Framework 6.20.30 php -v # > PHP 8.0.8 nginx -v # > nginx version: nginx/1.12.2 git --version # > git version 2.32.0 1. DownloadBundleでエラー The specified key does not exist. （訳）指定されたキーは存在しません。 解決 これは単純に、.circleci/config.ymlディレクトリにs3へのアップロードの記載をしていなかったことが原因でした。 config.yml // 省略 - run: name: upload artifacts to s3 command: aws s3 cp lantern.zip s3://${AWS_S3_BUCKET_NAME} // 省略 参考 2. AfterInstallでエラー : ① Script does not exist at specified location （訳）スクリプトが指定された場所に存在しません 解決 原因は、AfterInstallイベントで使用されていたシェルスクリプトが反映されていなかったことでした。 scripts/after_install.shを追加したけれど、これが本番環境の方には反映されていませんでした。 なので、本番環境の方に同じようにディレクトリとファイルを作成。 # ① scriptsディレクトリ作成 $ mkdir scripts # ② scriptsディレクトリ内に移動して、after_install.shファイルを作成 [scripts] $ touch after_install.sh # ③ ファイルの中を編集 [scripts] $ vi after_install.sh 以下は、after_install.shファイルの記述内容です。 after_install.sh #!/bin/bash set -eux cd ~/Lantern/lantern php artisan migrate --force php artisan config:cache よし、これでいけるだろう！と思い、もう一度デプロイ。。。 3. AfterInstallでエラー : ② Could not open input file: artisan （訳）入力ファイルを開くことができませんでした：artisan artisanコマンドが使えないということは指定しているディレクトリが違うのかな...と思ったので確認。 案の定、ディレクトリを指定しているところが違っていたため以下のように修正。 after_install.sh - cd ~/Lantern/lantern + cd ~/Lantern/lantern-ssh-deploy php artisan migrate --force php artisan config:cache よし、これでいけるだろう！！ 無事デプロイ完了！ おわりに 改めて振り返ると、ディレクトリの指定ミスがちらほらありました...。 少しはAWSと仲良くなれた気がします。 参考