20210426のPHPに関する記事は15件です。

PHPの基本操作⑥ 「ファイルアップロードの受信をする」

ファイルアップロードの受信をする
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PHPの基本操作⑦ 「ファイルアップロードの受信をする」

参考書籍 よくわかるPHPの教科書 PHP7対応版 他記事リンク PHPの基本操作①「簡単な出力と構文、配列、連想配列、少数、フォーマット」 PHPの基本操作②「ファイルの読み込み、ファイルの書き込み、XMLの読み込み、JSONの読み込み」 PHPの基本操作③「入力欄、ラジオボタン、チェックボックス」 PHPの基本操作④「数字かどうかの判定、正規表現、別ページにジャンプ」 PHPの基本操作⑤「クッキーとセッションの保存と取得」 PHPの基本操作⑥「電子メールの送信」 PHPの基本操作⑦「ファイルアップロードの受信をする」 ファイルアップロードの受信をする 送信元のフォーム 通常のフォームと違い、画像をアップロードする際には、に「enctype="multipart/form-data」と記載します。 →通常のフォーム+ファイルという意味 実際にファイルを添付するは「というタイプを選択します。 上記2点だけでファイルを送信できるフォームの完成です ※ファイルの送信時は必ずにするのを忘れない index.php <form action="submit.php" method="post" enctype="multipart/form-data"> <input type="text" name="ok" > <input type="file" name="picture"> <input type="submit" value="送信"> </form> データの受け取り先 アップロードされたファイルの取得をするためには「$_FILES」を利用します。連想配列としてファイルが保管されているため、「$_FILES['picture']」とキー(name属性値)を指定して取り出します。 (通常のフォームの内容であれば、「$_POST」で取得可能) 取り出した値はまたそれも連想配列になっています。 この連想配列の中身は決まっていて、以下のようになっています。 $file['name'] : ファイル名(name) $file['type'] : ファイルタイプ(type) $file['tmp_name']: アップロードされたファイル(tmp_name) $file['error'] : エラー内容(error) $file['size'] : サイズ(size) 「tmp_name」はアップロードしておくファイルの保管場所のパスとファイル名です。 入力欄(input type="file")→→→(アップロード)→→→tmpフォルダ→→→???→→→目的のフォルダ ここで「???」にあたる処理を行うのが、「move_uploaded_file関数」です。 tmp→目的ファイルへのアップロード処理 成功失敗 = move_uploaded_file(コピー元, コピー先) ファイルが目的の保存先に移動できれば、を使って画像を表示させることが可能です。 このようにファイルのアップロードは比較的に簡単に行えますが、ファイルアップロードはセキュリティ的に危険な入り口の一つです。そのため、セキュリティの対策の一環としてファイルの拡張子によるチェックを設けます。ファイル名の最後が「gif」「jpg」「png」もののみの受付にします。 この時に使うのが、ファイル名の切り取りできる「substr関数」です substr(ファイル名, 場所指定) 場所の指定の仕方は下記のようにします 前から3文字→3 後ろから3文字→-3 以上の処理を組み合わせた操作が以下のプログラムになります。 submit.php <?php $file = $_FILES['picture']; ?> ファイル名(name) : <?php print($file['name']); ?> ファイルタイプ(type) : <?php print($file['type']); ?> アップロードされたファイル(tmp_name) : <?php print($file['tmp_name']); ?> エラー内容(error) : <?php print($file['error']); ?> サイズ(size) <?php print($file['size']); ?> <?php $ext = substr($file['name'], -4); if ($ext == '.gif' || $ext == '.jpg' || $ext == '.png') : $filePath = './user_img/' . $file['name']; $success = move_uploaded_file($file['tmp_name'], $filePath); if($success) : ?> <img src="<?php print($filePath); ?>"> <?php endif; ?> ※拡張子が.gif, .jpg, .pngのいずれかのファイルをアップロードしてください <?php endif; ?> ※事前に移動先のパスにあたるファイルの作成をしておかなくてはならない
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PHPの基本操作⑥ 「電子メールの送信」

参考書籍 よくわかるPHPの教科書 PHP7対応版 他記事リンク PHPの基本操作①「簡単な出力と構文、配列、連想配列、少数、フォーマット」 PHPの基本操作②「ファイルの読み込み、ファイルの書き込み、XMLの読み込み、JSONの読み込み」 PHPの基本操作③「入力欄、ラジオボタン、チェックボックス」 PHPの基本操作④「数字かどうかの判定、正規表現、別ページにジャンプ」 PHPの基本操作⑤「クッキーとセッションの保存と取得」 PHPの基本操作⑥「電子メールの送信」 PHPの基本操作⑦「ファイルアップロードの受信をする」 電子メールを送信する PHPを使って、電子メールを送信する機能を実装します。 日本語でメールを送信する場合mb_send_mail関数を使います。戻り値として、成功の可否が返されます。 mb_send_mail(送り先のメールアドレス, 件名, 本文, 送り元のメールアドレス等) このファンクションを使う場合、PHPの設定で言語や文字コードを以下のように設定することで正しく動作します。 mb_language('japanese'); mb_internal_encoding('UTF-8'); 戻り値などを利用し、表示を変更するように実装すると以下のようになります。(メールサーバーの稼働やNDSサーバーの稼働が必要となるため、以下実行してもメールは送信されません。) 電子メールを送信する <?php $email = 'receive@example.com'; mb_language('japanese'); mb_internal_encoding('UTF-8'); $from = 'submit@example.com'; $subject = 'PHPの基本操作の練習'; $body = 'このメールは、「PHPの基本操作の練習」から送信しています'; $success = mb_send_mail($email, $subject, $body, 'From: ' . $from); ?> <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>PHPの基本操作の練習</title> </head> <body> <pre> <?php if($success) : ?> 電子メールを送信しました。メールボックスを確認してみてください。 <?php else : ?> 電子メールの送信に失敗しました。Webサーバーの設定などをご確認ください。 <?php endif; ?> </pre> </body> </html>   2種類のトップページをランダムに表示する ランダムな整数を生成するにはrand関数を使います ランダム関数の使い方 ランダムな値 = rand(最小の整数, 最大の整数); これを条件に用いたif文を使い、header関数を呼び出すことで、2種類のトップページをランダムに表示します。 2種類のトップページをランダムに表示します <?php if(rand(0, 1) == 0) { header('Location: a.html'); } else { header('Location: b.html'); } ?> a.html このページは、Aのページです。もう一度、ページを読み込んでみましょう。 b.html このページは、Bのページです。もう一度、ページを読み込んでみましょう。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MAMPでCakePHPを使う(2021年版)

会社の研修がきっかけでPHPを学習し始め、推奨されたフレームワークがCakePHPだった。CakePHPはMVCモデルを採用しているウェブアプリケーションフレームワークであり、Ruby on Railsの概念が取り入れられているらしい。 CakePHPについてググってみるだけでは不明点多しだったため、メルカリで「CakePHP超入門」という本を購入し早速ハンズオンしてみた。CakePHP用のDockerのimageを持っていたが、本に倣いcomposerを使った環境構築をした。だが三年前に出版された本ということもあり動かなかった点もあったため、備忘録ということで環境構築までの流れをまとめた。 環境 macOS Big Sur: 11.2.3 MAMP: 6.3 PHP: 7.4.12 CakePHP: 4.2.5 MAMPのインストール MAMP PROでない無料のMAMPをインストール。 composerのコマンドをターミナルで入力 ターミナルでディレクトリ位置をDesktopに移動。composerホームページでトップページ→Download内にコマンドが公開されているので入力。するとDesktopにcomposer.pharというファイルが作成される。 php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" php -r "if (hash_file('sha384', 'composer-setup.php') === '756890a4488ce9024fc62c56153228907f1545c228516cbf63f885e036d37e9a59d27d63f46af1d4d07ee0f76181c7d3') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" php composer-setup.php php -r "unlink('composer-setup.php');" ターミナルが見ているPHPの確認 $ which php ターミナルが見ているPHPはMacBook本体に入っているものか、MAMPのPHPかの確認。MAMPを起動し上記のコマンドを打つと、おそらく /usr/bin/php という結果が返ってくる。この結果をMAMPのPHPにする必要があるのでパスの指定が必要。 ちなみに… /usr/bin/php の状態でこの先進むと Problem 1 - cakephp/cakephp[4.2.0, ..., 4.2.5] require ext-intl * -> it is missing from your system. Install or enable PHP's intl extension. - Root composer.json requires cakephp/cakephp ~4.2.0 -> satisfiable by cakephp/cakephp[4.2.0, ..., 4.2.5]. 後のコマンドでintl extensionがないという上記の警告が表示されてしまい動作がおかしくなる。(自分も悩みました) MAMPのPHPのパスの指定 $ vi ~/.bashrc $ export PATH=/Applications/MAMP/bin/php/php7.4.12/bin:$PATH // :wq で保存 $ source ~/.bashrc // 変更の反映 ターミナルで上記コマンドを実行することによってMAMPのPHPのパスが通ります。この設定後に $ which php の実行で /Applications/MAMP/bin/php/php7.4.12/bin/php 通りましたね! CakePHPのコマンド実行! composer.pharがDesktopにある状態かつディレクトリ位置もDesktopの状態で php composer.phar create-project --prefer-dist cakephp/app アプリの名前 を実行し、permissionの確認でyを押すと、「アプリの名前」ディレクトリがDesktopに生成されました! その中にはbinやsrcなど多数入っています。そのディレクトリを丸ごと user/Applications/MAMP/htdocs 内に移動させ、ブラウザ環境で http://localhost:8888/アプリの名前/ にアクセスすると、 環境構築完了しました! この画面がCakePHPのHello World! のようなものです。Databaseはまだ触っていないのでアイコンが赤くなっています。(Databaseの設定をすればアイコンが緑になる) 参考文献 ・【CakePHP3系/MAMP】ComposerでCakePHP3系をインストール実行時、「Your requirements could not be resolved to an installable set of packages.」と怒られた時の解決方法 ・viの基本的な使い方 ・viで文字を削除するコマンド【色々な方法まとめました】
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PHPer向けのpre-commitで静的解析ライフ

追記と補足 Twitterにて諸先輩方からご指摘を頂いたのでそのやりとりを載せます。(許可もいただいてます) 僕はGitのpre-commitでPHPの静的解析するみたいなのは、あまりおすすめしないです。強く反対もしないですけど。— tadsan (@tadsan) April 26, 2021 コード整形や一定レベルのエラー検出 はIDEの解析で可能なのでその時点で直すのが一番いいと思うんですが、PHPStanなどのツールによる解析はどのタイミングで行うのが一番いいと思いますか?むしろIDEの解析が優秀ならPHPStanいらないんじゃ?という気もしてます— にしやま (@nsym__m) April 27, 2021 解析はコーディング中常時とPRに対するCIで行います。IDEも静的解析をしているので「IDEが優秀なら」と区切ることは無意味ですが、少なくとも現在のPhpStormはPsalmやPHPStanなどの検査能力と比べると検出される内容はやや貧弱です。 https://t.co/yIaFwmu7TA— tadsan (@tadsan) April 27, 2021 なるほど。「静的解析上問題のあるコードはプッシュすべきではない」という思想から今回のものを書いたのですが前提の思想が間違ってたのですね。リモートに上げること自体はOKで、その後PRで人の目が入る前提でその前処理としてCIで静的解析を行っておくべき、という理解であってますか?— にしやま (@nsym__m) April 27, 2021 はい。コミット単位やマージ前のコミットは不完全でもpushして構わないという立場です。もちろんこれは議論があるところですが、すべてのコミットの完全性を保ちながら作業するのはたいへんなので、僕はこまめにコミットしつつガンガンrebaseとforce pushします。— tadsan (@tadsan) April 27, 2021 あとこの辺も コミットが億劫になり、「まあいっか」で複数の変更を1コミットでまとめて行うようになり、クソコミットグラフになりがち— D.Horiyama (web技術) (@d_horiyama_web) April 26, 2021 Git の pre-commit でのPHPの静的解析に賛成しないというのは言っちゃえば音楽性の違いというだけなんだけど、とはいえ新卒の立場に立ってみるとローカルでコミットすらできないのとpushしたあとCIに怒られるのだと、おそらくPRの差分をメンバーと共有しながら確認できる後者の方がいい。— tadsan (@tadsan) April 27, 2021 PHPStanの検査が通ることよりも書いたプログラムが通る事実の方が大切。静的解析ツールには擬陽性があるので検査を通らなければコードが間違ってるとまで言うことはできない。— tadsan (@tadsan) April 26, 2021 上記の通りで、おっしゃる通りだと思ったので今はCIの時に静的解析意見が変わってます。 意見が変わったというか、 記事を書いていた時におぼろげながら浮かんできたんです。46という数字が。持っていた違和感が言語化されたような感じですね。 ただ、せっかく慣れないシェルスクリプト書いたしまぁ使えないわけではないので下の部分も残してはおきます。 あくまでもこの下は「こういうこともできるよ。でももっといい運用があるから特別推奨はしないよ。」程度の気持ちで読んでください。 PHPer向けのpre-commitスクリプト Gitに上げる前に静的解析する為に作りました。 ※Laravel想定なので、他のフレームワークの場合はphpstanの設定周りで若干読み替えてください。 pre-commitとは 設定した状態でgit commitを実行するとコミットの前にこのスクリプトが走り、内容に問題があるとコミットが中止されます。(適当) 構成 phpstan(larastan) php -l(phpstan成功時に実行) phpstanがどの程度検出できるか正直わからないので念の為 php-cs-fixer 特定ディレクトリ以下などを対象に実行してしまうと改修範囲が膨大になり導入コストが上がってしまう為、 既存プロジェクトなどへの導入コスト低減の為コミット対象のファイルにのみ実行させている。 pre-commitファイル シェルは慣れてないので書き方はよくないかもです。 もっと良い書き方があればコメントいただけると幸いです。 特にエラー判定のあたりは正直「本当にこれでいいのか?」と思いながら書いてます...。 あと後半は概ねデフォルトのまんま。 ↓がpre-commitのファイルです。 #!/bin/sh if git rev-parse --verify HEAD >/dev/null 2>&1 then against=HEAD else # Initial commit: diff against an empty tree object against=`git hash-object -t tree /dev/null` fi phpfiles=`git diff --name-only --diff-filter=d $against | grep \.php` if [ "$phpfiles" != "" ]; then echo '####\033[32m check phpstan \033[m####' echo '####\033[32m check php-cs-fixer \033[m####' echo '####\033[32m check php -l \033[m####' echo # ディレクトリ定義 ROOT_DIR=`git rev-parse --show-toplevel` # エラー定義 errorStan=false errorCs=false errorL=false for file in `git diff-index --name-status $against -- | grep -E '^[AUM].*\.php$'| cut -c3-` do # phpstan実行 全ファイルにチェックすると既存ファイルにエラーがある時コミットできないので、コミット対象のファイルのみチェックする phpstanCheck=`./vendor/bin/phpstan analyze --memory-limit=2G $ROOT_DIR/$file` # エラーがなければ'No errors'という文字列があるので、それがない場合にエラーと判断 echo $phpstanCheck | grep 'No errors' > /dev/null 2>&1 # $?には直前の実行結果が入る if [ $? != 0 ]; then echo "####\033[31m phpstan failed!!!! \033[m####$phpstanCheck\n" errorStan=true else # php -lによるシンタックスチェック実行 app/配下以外だとphpstanが実行されない気がする?為入れてる syntaxCheck=`php -l $file` # エラーがなければ'No syntax errors'という文字列があるので、それがない場合にエラーと判断 echo $syntaxCheck | grep 'No syntax errors' > /dev/null 2>&1 if [ $? != 0 ]; then # シンタックスエラーのあった場合はエラー内容を出力 echo "####\033[31m php -l failed!!!! \033[m####$syntaxCheck\n" errorL=true fi fi # php-cs-fixer実行 --dry-run で修正はせずに引っ掛かったらコミットさせずに修正を促す # --path-modeをintersectionにすることで、Finderが無視されないようにする .tools/php-cs-fixer/vendor/bin/php-cs-fixer fix --path-mode=intersection --dry-run $ROOT_DIR/$file > /dev/null 2>&1 if [ $? != 0 ]; then echo "####\033[31m php-cs-fixer failed!!!! \033[m####\n $ROOT_DIR/$file\n" errorCs=true fi done # "phpstan", "php-cs-fixer", "php -l"のどれかに引っ掛かっていたらコミットを中断 if "${errorStan}"; then echo "####\033[31m Commit fail\033[m please fix \033[31mphpstan errors\033[m ####" fi if "${errorL}"; then echo "####\033[31m Commit fail\033[m please \033[31msyntax check\033[m ####" fi if "${errorCs}"; then echo "####\033[31m Commit fail\033[m please run \033[31m\"tools/php-cs-fixer/vendor/bin/php-cs-fixer fix\"\033[m command ####" fi if [ $errorStan -o $errorL -o $errorCs ]; then exit 1 fi echo '####\033[32m phpstan, php -l, php-cs-fixer all completed!! \033[m####' fi # この下はほぼ`git init`で生成されたデフォルトのまま # If you want to allow non-ASCII filenames set this variable to true. allownonascii=$(git config --bool hooks.allownonascii) # Redirect output to stderr. exec 1>&2 # Cross platform projects tend to avoid non-ASCII filenames; prevent # them from being added to the repository. We exploit the fact that the # printable range starts at the space character and ends with tilde. if [ "$allownonascii" != "true" ] && # Note that the use of brackets around a tr range is ok here, (it's # even required, for portability to Solaris 10's /usr/bin/tr), since # the square bracket bytes happen to fall in the designated range. test $(git diff --cached --name-only --diff-filter=A -z $against | LC_ALL=C tr -d '[ -~]\0' | wc -c) != 0 then echo "####\033[31m ここでエラーの場合はコミットしたファイルに空白行に余分なスペースがある可能性があります。\033[m #### ####\033[31m もしどうしても解決できない場合は'git commit -m \"commit message\" --no-verify'でprecommitを無効化させてください。(非推奨) \033[m ####" cat <<\EOF #### Error: Attempt to add a non-ASCII file name. This can cause problems if you want to work with people on other platforms. To be portable it is advisable to rename the file. If you know what you are doing you can disable this check using: git config hooks.allownonascii true #### EOF exit 1 fi # If there are whitespace errors, print the offending file names and fail. exec git diff-index --check --cached $against -- Set up MacOS想定 Gitは導入済みな想定 Composerも導入済みな想定 静的解析に必要なライブラリの導入 各プロジェクトにphpstan(larastan)とphp-cs-fixerが導入されている前提なので、これらの導入が必要。 ここではLaravel想定なので、phpstanではなくlarastanを導入するが、Laravel以外の場合はphpstanを導入してください。下に導入方法も書いてますが、古い可能性もあるので以下リンクの公式のインストールガイドを参照してください。 nunomaduro/larastan phpstan/phpstan friendsofphp/php-cs-fixer phpstan(larastan)の導入 $ cd path/to/your/project $ composer require --dev nunomaduro/larastan # Laravel以外の場合 # $ composer require --dev phpstan/phpstan $ vim phpstan.neon # 好きなエディタでプロジェクトrootに以下を作成 ↓phpstan.neonです。ほぼ公式のまま。 # phpstan.neon(for larastan) includes: - ./vendor/nunomaduro/larastan/extension.neon parameters: paths: - app # The level 8 is the highest level level: 5 ignoreErrors: - '#Unsafe usage of new static#' excludePaths: checkMissingIterableValueType: false php-cs-fixerの導入 $ cd path/to/your/project $ mkdir -p tools/php-cs-fixer $ composer require --working-dir=tools/php-cs-fixer friendsofphp/php-cs-fixer $ echo .php_cs.cache >> .gitignore # .gitignoreに.php_cs.cacheを追記 $ vim .php_cs.dist # 好きなエディタでプロジェクトrootに以下を作成 ↓.php_cs.distです。 こちらはsuinさんのソースコードの“赤ペン先生”PHP-CS-Fixerのインストールと設定をありがたく流用させていただいていたような気がします。感謝。 .php_cs.distは長いので折りたたんでます。 <?php use PhpCsFixer\Config; use PhpCsFixer\Finder; $rules = [ 'array_syntax' => ['syntax' => 'short'], 'binary_operator_spaces' => [ 'default' => 'single_space', 'operators' => ['=>' => null] ], 'blank_line_after_namespace' => true, 'blank_line_after_opening_tag' => true, 'blank_line_before_statement' => [ 'statements' => ['return'] ], 'braces' => true, 'cast_spaces' => true, 'class_attributes_separation' => [ 'elements' => ['method'] ], 'class_definition' => true, 'concat_space' => [ 'spacing' => 'none' ], 'declare_equal_normalize' => true, 'elseif' => true, 'encoding' => true, 'full_opening_tag' => true, 'fully_qualified_strict_types' => true, // added by Shift 'function_declaration' => true, 'function_typehint_space' => true, 'heredoc_to_nowdoc' => true, 'include' => true, 'increment_style' => ['style' => 'post'], 'indentation_type' => true, 'linebreak_after_opening_tag' => true, 'line_ending' => true, 'lowercase_cast' => true, 'lowercase_constants' => true, 'lowercase_keywords' => true, 'lowercase_static_reference' => true, // added from Symfony 'magic_method_casing' => true, // added from Symfony 'magic_constant_casing' => true, 'method_argument_space' => true, 'native_function_casing' => true, 'no_alias_functions' => true, 'no_extra_blank_lines' => [ 'tokens' => [ 'extra', 'throw', 'use', 'use_trait', ] ], 'no_blank_lines_after_class_opening' => true, 'no_blank_lines_after_phpdoc' => true, 'no_closing_tag' => true, 'no_empty_phpdoc' => true, 'no_empty_statement' => true, 'no_leading_import_slash' => true, 'no_leading_namespace_whitespace' => true, 'no_mixed_echo_print' => [ 'use' => 'echo' ], 'no_multiline_whitespace_around_double_arrow' => true, 'multiline_whitespace_before_semicolons' => [ 'strategy' => 'no_multi_line' ], 'no_short_bool_cast' => true, 'no_singleline_whitespace_before_semicolons' => true, 'no_spaces_after_function_name' => true, 'no_spaces_around_offset' => true, 'no_spaces_inside_parenthesis' => true, 'no_trailing_comma_in_list_call' => true, 'no_trailing_comma_in_singleline_array' => true, 'no_trailing_whitespace' => true, 'no_trailing_whitespace_in_comment' => true, 'no_unneeded_control_parentheses' => true, 'no_unreachable_default_argument_value' => true, 'no_useless_return' => true, 'no_whitespace_before_comma_in_array' => true, 'no_whitespace_in_blank_line' => true, 'normalize_index_brace' => true, 'not_operator_with_successor_space' => true, 'object_operator_without_whitespace' => true, 'ordered_imports' => ['sortAlgorithm' => 'alpha'], 'phpdoc_indent' => true, 'phpdoc_inline_tag' => true, 'phpdoc_no_access' => true, 'phpdoc_no_package' => true, 'phpdoc_no_useless_inheritdoc' => true, 'phpdoc_scalar' => true, 'phpdoc_single_line_var_spacing' => true, 'phpdoc_summary' => true, 'phpdoc_to_comment' => true, 'phpdoc_trim' => true, 'phpdoc_types' => true, 'phpdoc_var_without_name' => true, 'psr4' => true, 'self_accessor' => true, 'short_scalar_cast' => true, 'simplified_null_return' => false, // disabled by Shift 'single_blank_line_at_eof' => true, 'single_blank_line_before_namespace' => true, 'single_class_element_per_statement' => true, 'single_import_per_statement' => true, 'single_line_after_imports' => true, 'single_line_comment_style' => [ 'comment_types' => ['hash'] ], 'single_quote' => true, 'space_after_semicolon' => true, 'standardize_not_equals' => true, 'switch_case_semicolon_to_colon' => true, 'switch_case_space' => true, 'ternary_operator_spaces' => true, 'trailing_comma_in_multiline_array' => true, 'trim_array_spaces' => true, 'unary_operator_spaces' => true, 'visibility_required' => [ 'elements' => ['method', 'property'] ], 'whitespace_after_comma_in_array' => true, ]; $finder = Finder::create() ->in([ __DIR__ . '/app', __DIR__ . '/config', __DIR__ . '/database', __DIR__ . '/resources', __DIR__ . '/routes', __DIR__ . '/tests', ]) ->name('*.php') ->notName('*.blade.php') ->ignoreDotFiles(true) ->ignoreVCS(true); return Config::create() ->setFinder($finder) ->setRules($rules) ->setRiskyAllowed(true) ->setUsingCache(true); ※これ以下のgitの設定については詳しくは公式ドキュメントを参照してください。 端末の全リポジトリに共通で設定する場合 {pre-commitファイルをダウンロード} $ mkdir -p ~/.config/git/hooks $ mv ~/Downloads/pre-commit ~/.config/git/hooks/pre-commit $ chmod +x ~/.config/git/hooks/pre-commit $ git config --global core.hooksPath '~/.config/git/hooks' 既にclone済みの特定のリポジトリにのみ設定する場合 {pre-commitファイルをダウンロード} $ cd path/to/your/project $ mkdir .git/hooks $ mv ~/Downloads/pre-commit .git/hooks/pre-commit $ chmod +x .git/hooks/pre-commit 既存のリポジトリには設定したくないが、これから新規にcloneするリポジトリは全て反映させたい場合 {pre-commitファイルをダウンロード} $ mkdir -p ~/.git_template/hooks $ mv ~/Downloads/pre-commit ~/.git_template/hooks/pre-commit $ chmod +x ~/.git_template/hooks/pre-commit $ git config --global init.templatedir '~/.git_template/hooks' 実行 こんな風になります。 ちなみに既知の不具合として、Sourcetreeで行うと色が微妙な感じになりますが、対応する予定はありません。 余談 本当はこれはエディタレベルでやってしまいたい。 VS CodeのintelephenseというPHPの拡張機能が優秀なのでみんな入れましょうね。 余裕ができたらGitLabのCI環境も整備したい。 素敵な静的解析ライフを!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

お兄ちゃん、LaravelとVue.jsの連携ってどうやるの?npmってなに?バナナはおやつに入る?

概要 この記事は、Laravel8でVue.jsを連携利用しようとするも、事前準備段階で早々につまづいてしまった1人の少女の数奇な運命を綴る冒険談トラブルシューティング談です。基本的にポエムです。ご了承ください。なお、Node.jsの環境構築方法や「そもそもNode.js、Vue.jsって何?」の部分にはほとんど触れていません。ご承知おきください。 おいおいおい、おいおいおいおい、Vueなんて、どこにも書いていないじゃあないか より良いアプリケーションにはより良いUI/UXが必要。より良いUI/UXを実装するためにはモダンなフロントエンドフレームワークとの連携が不可欠だッ!ということでLaravelの技術書を参考にVue.jsのセットアップをしようとしていた時に、事件は起こりました。 技術書によると、セットアップの手順は以下の通り。 createしたLaravelアプリにはpackage.jsonファイルが標準で用意されている $ npm installコマンドでpackage.json内に記述されたパッケージ類を全てインストールする $ npm run devコマンドでLaravelアプリをビルドし、インストールしたVue.jsを実際に使えるようにする あーそーゆーことね、完全に理解した。「言葉」でなく「心」で理解できたよッ!これなら私にもできりゅっ!とトゥインクルトゥインクルしていたのも束の間、次の文を読んだ瞬間、私は身の毛もよ立つような恐怖の渦きを味わうのであった。 package.jsonのdevDependenciesに、使用されるパッケージがまとめられています。ここで、"vue"と"vue-template-compiler"が見えるでしょう。これらがvue.js利用のパッケージです。 ここで、私のpacakege.jsonを見てみましょう。こちらが私のpackage.jsonです。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } ここで、"vue"と"vue-template-compiler"が見えるでしょう。 あれ…見えないな…。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } "vue"と"vue-template-compiler"が見えるでしょう。 いいえ、見えません。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } 見えるでしょう。(n回目) おいおいおい、おいおいおいおい、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } Vueなんて、ましてやvue-template-compilerなんて、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } どこにも書いていないじゃあないか!! これはまさか…スタンドの仕業ッ!? いやいやっ、落ち着け私。私はそんなにヤワな女じゃないわ。 1人海外旅行中にトイレ詰まらせた時だって、親にソシャゲへの多額の課金がバレた時だって冷静に対処したじゃない…!! それに比べたらこんなの屁のカッパ、ちゃーら、へっちゃらなんだからッ…!! 今回だって乗り越えるわ、登り切ってやるッ!!!!! そもそも、npmとpackage.jsonでなにをしようとしてるのか npmとは npmとは、パッケージ管理システムの一種。Node Package Managerの意。 Node.jsは、サーバ上で動作するJavaScriptであるが、Node.jsを使ったツールが開発されるようになると、これらを管理するバージョン管理システムの必要性が生まれた。 npmは、Node.jsのツールやパッケージ(モジュール)をインストールしたり管理したりするだけでなく、パッケージを扱うためにインターフェイスを備えている。リポジトリ機能も備えており、必要とするパッケージ(モジュール)の検索、ダウンロード、インストール、アップデートを行えたり、開発したパッケージ(モジュール)を他者に公開できたりする。 フリー百科事典『ウィキペディア(Wikipedia)』より クッ…長い…これもスタンドの仕業か…?ということで、自分の言葉でまとめてみます。 Node.jsはそもそも、「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」っていう発想から生まれたサーバサイドのJavaScript実行環境のことでした。 npmは、このNode.jsのライブラリやフレームワークを一括管理してくれる便利ツールです。PHPでいうcomposer、Rubyでいうgem、Pythonでいうpip、Goでいうglideなどと一緒ですね。 これらを踏まえて整理すると、手順1~3で私がやろうとしていたことはすなわち 「Node.jsのnpmを使ってJavaScriptのフロントエンドフレームワーク(の一種)であるVue.jsを、開発中のLaravelアプリに組み込むこと」 ということになります。一文でまとめると「なんだ当たり前じゃん」感が出ちゃうんですけど、フロントエンドのフレームワークであるVue.jsを、サーバサイド側から取り込んじゃうって、結構画期的なんですよね。わざわざ<script>...</script>タグ使ってフロントエンド側でCDN呼び出さなくてよかったり、したがってリクエスト数が減らせるといったメリットがあるからです。 ここで、見落としていたロジックに気付く 先ほど、Node.jsは「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」という発想から生まれたサーバサイドのJavaScript実行環境のことである、と書きました。そう、まさにこのNode.js発祥の原点こそが、私を混乱の渦へと引きずり込んだ犯人だったのです。 調べたところ、今回の文脈では、Node.jsは「サーバサイドJavaScript実行環境」ではなく、「クライアントサイドJavaScriptの開発環境」と考えるのが正しかったようです。 だって、よくよく考えてみたら私、サーバサイドの処理はJavaScriptじゃなくてPHPで書いてるもん。Vue.jsはフロントエンド開発のフレームワーク、Laravelはサーバサイド開発のフレームワークだもん。 サーバサイドJavaScriptの高速処理が実現したことによって、サーバサイドJavaScript自体のパッケージ(Node.jsフレームワークExpressなど)だけじゃなく、クライアントサイドJavaScript開発にも便利なパッケージが次々と誕生した、というのは確かに自然な流れですね。 つまり、LaravelとVue.js連携において、サーバサイドにおけるNode.jsの役割はnpmを使えるようにするというただそれだけにあって、サーバサイドとフロントエンドではなお別々の言語、別々のロジックが働いている。ということが、Node.jsが一枚噛んだことによって見えなくなっていたんですね。 では、どうすればいいか Node.jsはクライアントサイドJavaScriptの「開発環境」であり、Vue.jsはフロントエンド開発のフレームワークである。ということは、必要なのはVue.jsの「実行環境」じゃあないか!!! JavaScriptで動くものを「作る」ための「開発環境」と、「作る」作業を効率的にする「枠組み」が揃っていても、それを実際に動かすための「実行環境」がないと動くものも動かないからです。 で、その実行環境を構築してくれるのが、かのLaravel/uiだったんですね!! すげー爽やかな気分だぜ!!新しいパンツを履いたばかりの正月元旦の朝のように!! こちらはLaravelのパッケージなのでcomposerでインストールします。 $ composer require laravel/ui フロントエンドスカフォールドが生成されたので、Vueのスカフォールドをセットアップします。 $ php artisan ui vue --auth Vue scaffolding installed successfully. Please run "npm install && npm run dev" to compile your fresh scaffolding. Authentication scaffolding generated successfully. ついに… package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "bootstrap": "^4.0.0", "jquery": "^3.2", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "popper.js": "^1.12", "postcss": "^8.1.14", "resolve-url-loader": "^3.1.2", "sass": "^1.20.1", "sass-loader": "^8.0.0", "vue": "^2.5.17", "vue-template-compiler": "^2.6.10" } } ついに現れたああああああああああああ!!! 見える…見えるよお兄ちゃん…僕にもvueとvue-template-compilerという文字が… これでやっとnpmコマンドが使えるようになったね… $ npm install フッ、ここまできたらどんなエラーも貧弱、貧弱ゥ!! 頑張れ!私はここまでよくやってきた!私はできる子!そして今日もこれからも!私が挫けることは絶対にないんだ!モード に突入しました。 ここまできたらどんなエラーが返ってこようが恐れることはありません。 RunとかRunning以下のコマンドをそのまま打ち込めばいいだけです。 # Run npm install --save-dev resolve-url-loader@3.1.2 to resolve 1 vulnerability Additional dependencies must be installed. This will only take a moment. Running: npm install vue-loader@^15.9.5 --save-dev --legacy-peer-deps 準備が整ったら、最後にビルドします。 $ npm run dev VueのExampleComponentsも用意されました。 勝った…。 勝ったんだ…この戦いに…。 終わりに 今回はLaravelとVue.jsの連携にlaravel/uiを利用しました。が、Laravel8では2021/4/26現在、認証系推奨ライブラリがlaravel/jetstremあるいはlaravel/breezeに変更になっています。1年前の情報はもう既に古くなってる、みたいな変化の激しい世界ですが、この目まぐるしさもまたモダンフレームワークの妙だなあと感じます。 終始ふざけてしまって恐縮ですが、この記事を読んでLaravelないしVue.jsの理解が少しでも深まったよ!という方が一人でもいたなら幸いです。ここまでお付き合いいただいた方、ありがとうございました! 参考 JavaScriptとCSSの足場:Laravel公式ドキュメント laravel/ui:GitHub npmのpackage.jsonと依存関係を理解しよう:bagelee Node.jsとはなにか?なぜみんな使っているのか?:Qiita Awesome Node.js : 素晴しい Node.js フレームワーク・ライブラリ・ソフトウェア・リソースの数々:Qiita npm入門:Qiita 「実行環境」と「開発環境」の違い:「分かりそう」で「分からない」でも「分かった」気になれるIT用語
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

お兄ちゃん、Laravel8とVue.jsの連携ってどうやるの?npmってなに?バナナはおやつに入る?

概要 この記事は、Laravel8でVue.jsを連携利用しようとするも、事前準備段階で早々につまづいてしまった1人の少女の数奇な運命を綴る冒険談トラブルシューティング談です。基本的にポエムです。ご了承ください。なお、Node.jsの環境構築方法や「そもそもVue.jsって何?」の部分にはほとんど触れていません。ご承知おきください。 おいおいおい、おいおいおいおい、Vueなんて、どこにも書いていないじゃあないか より良いアプリケーションにはより良いUI/UXが必要。より良いUI/UXを実装するためにはモダンなフロントエンドフレームワークとの連携が不可欠だッ!ということでLaravelの入門書を参考にVue.jsのセットアップをしようとしていた時に、事件は起こりました。 入門書によると、セットアップの手順は以下の通り。 createしたLaravelアプリにはpackage.jsonファイルが標準で用意されている $ npm installコマンドでpackage.json内に記述されたパッケージ類を全てインストールする $ npm run devコマンドでLaravelアプリをビルドし、インストールしたVue.jsを実際に使えるようにする あーそーゆーことね、完全に理解した。「言葉」でなく「心」で理解できたよッ!これなら私にもできりゅっ!とトゥインクルトゥインクルしていたのも束の間、次の文を読んだ瞬間、私は身の毛もよ立つような恐怖の渦きを味わうのであった。 package.jsonのdevDependenciesに、使用されるパッケージがまとめられています。ここで、"vue"と"vue-template-compiler"が見えるでしょう。これらがvue.js利用のパッケージです。 ここで、私のpacakege.jsonを見てみましょう。こちらが私のpackage.jsonです。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } ここで、"vue"と"vue-template-compiler"が見えるでしょう。 あれ…見えないな…。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } "vue"と"vue-template-compiler"が見えるでしょう。 いいえ、見えません。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } 見えるでしょう。(n回目) おいおいおい、おいおいおいおい、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } Vueなんて、ましてやvue-template-compilerなんて、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } どこにも書いていないじゃあないか!! これはまさか…スタンドの仕業ッ!? いやいやっ、落ち着け私。私はそんなにヤワな女じゃないわ。 1人海外旅行中にトイレ詰まらせた時だって、親にソシャゲへの多額の課金がバレた時だって冷静に対処したじゃない…!! それに比べたらこんなの屁のカッパ、ちゃーら、へっちゃらなんだからッ…!! 今回だって乗り越えるわ、登り切ってやるッ!!!!! そもそも、npmとpackage.jsonでなにをしようとしてるのか npmとは npmとは、パッケージ管理システムの一種。Node Package Managerの意。 Node.jsは、サーバ上で動作するJavaScriptであるが、Node.jsを使ったツールが開発されるようになると、これらを管理するバージョン管理システムの必要性が生まれた。 npmは、Node.jsのツールやパッケージ(モジュール)をインストールしたり管理したりするだけでなく、パッケージを扱うためにインターフェイスを備えている。リポジトリ機能も備えており、必要とするパッケージ(モジュール)の検索、ダウンロード、インストール、アップデートを行えたり、開発したパッケージ(モジュール)を他者に公開できたりする。 フリー百科事典『ウィキペディア(Wikipedia)』より クッ…長い…これもスタンドの仕業か…?ということで、自分の言葉でまとめてみます。 Node.jsはそもそも、「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」っていう発想から生まれたサーバサイドのJavaScript実行環境のことでした。 npmは、このNode.jsのライブラリやフレームワークを一括管理してくれる便利ツールです。PHPでいうcomposer、Rubyでいうgem、Pythonでいうpip、Goでいうglideなどと一緒ですね。 これらを踏まえて整理すると、手順1~3で私がやろうとしていたことはすなわち 「Node.jsのnpmを使ってJavaScriptのフロントエンドフレームワーク(の一種)であるVue.jsを、開発中のLaravelアプリに組み込むこと」 ということになります。一文でまとめると「なんだ当たり前じゃん」感が出ちゃうんですけど、フロントエンドのフレームワークであるVue.jsを、サーバサイド側から取り込んじゃうって、結構画期的なんですよね。わざわざ<script>...</script>タグ使ってフロントエンド側でCDN呼び出さなくてよかったり、したがってリクエスト数が減らせるといったメリットがあるからです。 ここで、見落としていたロジックに気付く 先ほど、Node.jsは「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」という発想から生まれたサーバサイドのJavaScript実行環境のことである、と書きました。そう、まさにこのNode.js発祥の原点こそが、私を混乱の渦へと引きずり込んだ犯人だったのです。 調べたところ、今回の文脈では、Node.jsは「サーバサイドJavaScriptの実行環境」ではなく、「クライアントサイドJavaScriptの開発環境」と考えるのが正しかったようです。 だって、よくよく考えてみたら私、サーバサイドの処理はJavaScriptじゃなくてPHPで書いてるもん。Vue.jsはフロントエンド開発のフレームワーク、Laravelはサーバサイド開発のフレームワークだもん。 サーバサイドJavaScriptの高速処理が実現したことによって、サーバサイドJavaScript自体のパッケージ(Node.jsフレームワークExpressなど)だけじゃなく、クライアントサイドJavaScript開発にも便利なパッケージが次々と誕生した、というのは確かに自然な流れですね。 この「自然な流れ」の部分がすっぽり抜けてしまうと、サーバサイドでJavaScript以外の言語を使用してる状況で「え、なんでNode.jsインストールしなきゃならんの?、npm?え?え?」みたいなことになってしまいます。 つまり、LaravelとVue.js連携において、サーバサイドにおけるNode.jsの役割はnpmを使えるようにするというただそれだけにあって、サーバサイドとフロントエンドではなお別々の言語、別々のロジックが働いている。ということが、Node.jsが一枚噛んだことによって見えなくなっていたんですね。 では、どうすればいいか Node.jsはクライアントサイドJavaScriptの「開発環境」であり、Vue.jsはフロントエンド開発のフレームワークである。ということは、必要なのはVue.jsの「実行環境」じゃあないか!!! JavaScriptで動くものを「作る」ための「開発環境」と、「作る」作業を効率的にする「枠組み」が揃っていても、それを実際に「動かす」ための「実行環境」がないと動くものも動かないからです。 で、その実行環境を構築してくれるのが、かのLaravel/uiだったんですね!! すげー爽やかな気分だぜ!!新しいパンツを履いたばかりの正月元旦の朝のように!! こちらはLaravelのパッケージなのでcomposerでインストールします。 $ composer require laravel/ui フロントエンドスカフォールドが生成されたので、Vueのスカフォールドをセットアップします。 $ php artisan ui vue --auth Vue scaffolding installed successfully. Please run "npm install && npm run dev" to compile your fresh scaffolding. Authentication scaffolding generated successfully. ついに… package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "bootstrap": "^4.0.0", "jquery": "^3.2", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "popper.js": "^1.12", "postcss": "^8.1.14", "resolve-url-loader": "^3.1.2", "sass": "^1.20.1", "sass-loader": "^8.0.0", "vue": "^2.5.17", "vue-template-compiler": "^2.6.10" } } ついに現れたああああああああああああ!!! 見える…見えるよお兄ちゃん…僕にもvueとvue-template-compilerという文字が… これでやっとVue.jsがインストールできるね… $ npm install フッ、ここまできたらどんなエラーも貧弱、貧弱ゥ!! 頑張れ!私はここまでよくやってきた!私はできる子!そして今日もこれからも!私が挫けることは絶対にないんだ!モード に突入しました。 ここまできたらどんなエラーが返ってこようが恐れることはありません。 RunとかRunning以下のコマンドをそのまま打ち込めばいいだけです。 # Run npm install --save-dev resolve-url-loader@3.1.2 to resolve 1 vulnerability Additional dependencies must be installed. This will only take a moment. Running: npm install vue-loader@^15.9.5 --save-dev --legacy-peer-deps 準備が整ったら、最後にビルドします。 $ npm run dev VueのExampleComponentsも用意されました。 勝った…。 勝ったんだ…この戦いに…。 終わりに 今回はLaravelとVue.jsの連携にlaravel/uiを利用しました。が、Laravel8では2021/4/26現在、認証系の処理に関しては推奨ライブラリがlaravel/jetstremあるいはlaravel/breezeに変更になっています。1年前の情報はもう既に古くなってる、みたいな変化の激しい世界ですが、この目まぐるしさもまたモダンフレームワークの妙だなあと感じます。 終始ふざけてしまって恐縮ですが、この記事を読んでLaravelないしNode.js、npm、Vue.jsの理解が少しでも深まったよ!という方が一人でもいたなら幸いです。ここまでお付き合いいただいた方、ありがとうございました! 参考 JavaScriptとCSSの足場:Laravel公式ドキュメント laravel/ui:GitHub npmのpackage.jsonと依存関係を理解しよう:bagelee Node.jsとはなにか?なぜみんな使っているのか?:Qiita Awesome Node.js : 素晴しい Node.js フレームワーク・ライブラリ・ソフトウェア・リソースの数々:Qiita npm入門:Qiita 「実行環境」と「開発環境」の違い:「分かりそう」で「分からない」でも「分かった」気になれるIT用語
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

お兄ちゃん、Laravel8とVue.jsの連携ってどうやるの?npmで一体なにをしようとしてるの?バナナはおやつに入る?

概要 この記事は、Laravel8でVue.jsを連携利用しようとするも、事前準備段階で早々につまづいてしまった1人の少女の数奇な運命を綴る冒険談トラブルシューティング談です。基本的にポエムです。ご了承ください。なお、Node.jsの環境構築方法や「そもそもVue.jsって何?」の部分にはほとんど触れていません。ご承知おきください。 おいおいおい、おいおいおいおい、Vueなんて、どこにも書いていないじゃあないか より良いアプリケーションにはより良いUI/UXが必要。より良いUI/UXを実装するためにはモダンなフロントエンドフレームワークとの連携が不可欠だッ!ということでLaravelの技術書を参考にVue.jsのセットアップをしようとしていた時に、事件は起こりました。 技術書によると、セットアップの手順は以下の通り。 createしたLaravelアプリにはpackage.jsonファイルが標準で用意されている $ npm installコマンドでpackage.json内に記述されたパッケージ類を全てインストールする $ npm run devコマンドでLaravelアプリをビルドし、インストールしたVue.jsを実際に使えるようにする あーそーゆーことね、完全に理解した。「言葉」でなく「心」で理解できたよッ!これなら私にもできりゅっ!とトゥインクルトゥインクルしていたのも束の間、次の文を読んだ瞬間、私は身の毛もよ立つような恐怖の渦きを味わうのであった。 package.jsonのdevDependenciesに、使用されるパッケージがまとめられています。ここで、"vue"と"vue-template-compiler"が見えるでしょう。これらがvue.js利用のパッケージです。 ここで、私のpacakege.jsonを見てみましょう。こちらが私のpackage.jsonです。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } ここで、"vue"と"vue-template-compiler"が見えるでしょう。 あれ…見えないな…。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } "vue"と"vue-template-compiler"が見えるでしょう。 いいえ、見えません。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } 見えるでしょう。(n回目) おいおいおい、おいおいおいおい、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } Vueなんて、ましてやvue-template-compilerなんて、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } どこにも書いていないじゃあないか!! これはまさか…スタンドの仕業ッ!? いやいやっ、落ち着け私。私はそんなにヤワな女じゃないわ。 1人海外旅行中にトイレ詰まらせた時だって、親にソシャゲへの多額の課金がバレた時だって冷静に対処したじゃない…!! それに比べたらこんなの屁のカッパ、ちゃーら、へっちゃらなんだからッ…!! 今回だって乗り越えるわ、登り切ってやるッ!!!!! そもそも、npmとpackage.jsonでなにをしようとしてるのか npmとは npmとは、パッケージ管理システムの一種。Node Package Managerの意。 Node.jsは、サーバ上で動作するJavaScriptであるが、Node.jsを使ったツールが開発されるようになると、これらを管理するバージョン管理システムの必要性が生まれた。 npmは、Node.jsのツールやパッケージ(モジュール)をインストールしたり管理したりするだけでなく、パッケージを扱うためにインターフェイスを備えている。リポジトリ機能も備えており、必要とするパッケージ(モジュール)の検索、ダウンロード、インストール、アップデートを行えたり、開発したパッケージ(モジュール)を他者に公開できたりする。 フリー百科事典『ウィキペディア(Wikipedia)』より クッ…長い…これもスタンドの仕業か…?ということで、自分の言葉でまとめてみます。 Node.jsはそもそも、「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」っていう発想から生まれたサーバサイドのJavaScript実行環境のことでした。 npmは、このNode.jsのライブラリやフレームワークを一括管理してくれる便利ツールです。PHPでいうcomposer、Rubyでいうgem、Pythonでいうpip、Goでいうglideなどと一緒ですね。 これらを踏まえて整理すると、手順1~3で私がやろうとしていたことはすなわち 「Node.jsのnpmを使ってJavaScriptのフロントエンドフレームワーク(の一種)であるVue.jsを、開発中のLaravelアプリに組み込むこと」 ということになります。一文でまとめると「なんだ当たり前じゃん」感が出ちゃうんですけど、フロントエンドのフレームワークであるVue.jsを、サーバサイド側から取り込んじゃうって、結構画期的なんですよね。わざわざ<script>...</script>タグ使ってフロントエンド側でCDN呼び出さなくてよかったり、したがってリクエスト数が減らせるといったメリットがあるからです。 ここで、見落としていたロジックに気付く 先ほど、Node.jsは「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」という発想から生まれたサーバサイドのJavaScript実行環境のことである、と書きました。そう、まさにこのNode.js発祥の原点こそが、私を混乱の渦へと引きずり込んだ犯人だったのです。 調べたところ、今回の文脈では、Node.jsは「サーバサイドJavaScriptの実行環境」ではなく、「クライアントサイドJavaScriptの開発環境」と考えるのが正しかったようです。 だって、よくよく考えてみたら私、サーバサイドの処理はJavaScriptじゃなくてPHPで書いてるもん。Vue.jsはフロントエンド開発のフレームワーク、Laravelはサーバサイド開発のフレームワークだもん。 サーバサイドJavaScriptの高速処理が実現したことによって、サーバサイドJavaScript自体のパッケージ(Node.jsフレームワークExpressなど)だけじゃなく、クライアントサイドJavaScript開発にも便利なパッケージが次々と誕生した、というのは確かに自然な流れですね。 この「自然な流れ」の部分がすっぽり抜けてしまうと、サーバサイドでJavaScript以外の言語を使用してる状況で「え、なんでNode.jsインストールしなきゃならんの?、npm?え?え?」てなことになってしまいます。 つまり、LaravelとVue.js連携において、サーバサイドにおけるNode.jsの役割はnpmを使えるようにするというただそれだけにあって、サーバサイドとフロントエンドではなお別々の言語、別々のロジックが働いている。ということが、Node.jsが一枚噛んだことによって見えなくなっていたんですね。 では、どうすればいいか Node.jsはクライアントサイドJavaScriptの「開発環境」であり、Vue.jsはフロントエンド開発のフレームワークである。ということは、必要なのはVue.jsの「実行環境」じゃあないか!!! JavaScriptで動くものを「作る」ための「開発環境」と、「作る」作業を効率的にする「枠組み」が揃っていても、それを実際に「動かす」ための「実行環境」がないと動くものも動かないからです。 で、その実行環境を構築してくれるのが、かのLaravel/uiだったんですね!! すげー爽やかな気分だぜ!!新しいパンツを履いたばかりの正月元旦の朝のように!! こちらはLaravelのパッケージなのでcomposerでインストールします。 $ composer require laravel/ui フロントエンドスカフォールドが生成されたので、Vueのスカフォールドをセットアップします。 $ php artisan ui vue --auth Vue scaffolding installed successfully. Please run "npm install && npm run dev" to compile your fresh scaffolding. Authentication scaffolding generated successfully. ついに… package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "bootstrap": "^4.0.0", "jquery": "^3.2", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "popper.js": "^1.12", "postcss": "^8.1.14", "resolve-url-loader": "^3.1.2", "sass": "^1.20.1", "sass-loader": "^8.0.0", "vue": "^2.5.17", "vue-template-compiler": "^2.6.10" } } ついに現れたああああああああああああ!!! 見える…見えるよお兄ちゃん…僕にもvueとvue-template-compilerという文字が… これでやっとnpmコマンドが使えるようになったね… $ npm install フッ、ここまできたらどんなエラーも貧弱、貧弱ゥ!! 頑張れ!私はここまでよくやってきた!私はできる子!そして今日もこれからも!私が挫けることは絶対にないんだ!モード に突入しました。 ここまできたらどんなエラーが返ってこようが恐れることはありません。 RunとかRunning以下のコマンドをそのまま打ち込めばいいだけです。 # Run npm install --save-dev resolve-url-loader@3.1.2 to resolve 1 vulnerability Additional dependencies must be installed. This will only take a moment. Running: npm install vue-loader@^15.9.5 --save-dev --legacy-peer-deps 準備が整ったら、最後にビルドします。 $ npm run dev VueのExampleComponentsも用意されました。 勝った…。 勝ったんだ…この戦いに…。 終わりに 今回はLaravelとVue.jsの連携にlaravel/uiを利用しました。が、Laravel8では2021/4/26現在、認証系推奨ライブラリがlaravel/jetstremあるいはlaravel/breezeに変更になっています。1年前の情報はもう既に古くなってる、みたいな変化の激しい世界ですが、この目まぐるしさもまたモダンフレームワークの妙だなあと感じます。 終始ふざけてしまって恐縮ですが、この記事を読んでLaravelないしNode.js、npm、Vue.jsの理解が少しでも深まったよ!という方が一人でもいたなら幸いです。ここまでお付き合いいただいた方、ありがとうございました! 参考 JavaScriptとCSSの足場:Laravel公式ドキュメント laravel/ui:GitHub npmのpackage.jsonと依存関係を理解しよう:bagelee Node.jsとはなにか?なぜみんな使っているのか?:Qiita Awesome Node.js : 素晴しい Node.js フレームワーク・ライブラリ・ソフトウェア・リソースの数々:Qiita npm入門:Qiita 「実行環境」と「開発環境」の違い:「分かりそう」で「分からない」でも「分かった」気になれるIT用語
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

お兄ちゃん、LaravelとVue.jsの連携にどうしてlaravel/uiが必要なの?npmでなにをしようとしているの?バナナはおやつに入る?

概要 この記事は、Laravel8でVue.jsを連携利用しようとするも、事前準備段階で早々につまづいてしまった1人の少女の数奇な運命を綴る冒険談トラブルシューティング談です。基本的にポエムです。ご了承ください。なお、Node.jsの環境構築方法や「そもそもVue.jsって何?」の部分にはほとんど触れていません。ご承知おきください。 おいおいおい、おいおいおいおい、Vueなんて、どこにも書いていないじゃあないか より良いアプリケーションにはより良いUI/UXが必要。より良いUI/UXを実装するためにはモダンなフロントエンドフレームワークとの連携が不可欠だッ!ということでLaravelの技術書を参考にVue.jsのセットアップをしようとしていた時に、事件は起こりました。 技術書によると、セットアップの手順は以下の通り。 createしたLaravelアプリにはpackage.jsonファイルが標準で用意されている $ npm installコマンドでpackage.json内に記述されたパッケージ類を全てインストールする $ npm run devコマンドでLaravelアプリをビルドし、インストールしたVue.jsを実際に使えるようにする あーそーゆーことね、完全に理解した。「言葉」でなく「心」で理解できたよッ!これなら私にもできりゅっ!とトゥインクルトゥインクルしていたのも束の間、次の文を読んだ瞬間、私は身の毛もよ立つような恐怖の渦きを味わうのであった。 package.jsonのdevDependenciesに、使用されるパッケージがまとめられています。ここで、"vue"と"vue-template-compiler"が見えるでしょう。これらがvue.js利用のパッケージです。 ここで、私のpacakege.jsonを見てみましょう。こちらが私のpackage.jsonです。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } ここで、"vue"と"vue-template-compiler"が見えるでしょう。 あれ…見えないな…。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } "vue"と"vue-template-compiler"が見えるでしょう。 いいえ、見えません。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } 見えるでしょう。(n回目) おいおいおい、おいおいおいおい、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } Vueなんて、ましてやvue-template-compilerなんて、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } どこにも書いていないじゃあないか!! これはまさか…スタンドの仕業ッ!? いやいやっ、落ち着け私。私はそんなにヤワな女じゃないわ。 1人海外旅行中にトイレ詰まらせた時だって、親にソシャゲへの多額の課金がバレた時だって冷静に対処したじゃない…!! それに比べたらこんなの屁のカッパ、ちゃーら、へっちゃらなんだからッ…!! 今回だって乗り越えるわ、登り切ってやるッ!!!!! そもそも、npmとpackage.jsonでなにをしようとしてるのか npmとは npmとは、パッケージ管理システムの一種。Node Package Managerの意。 Node.jsは、サーバ上で動作するJavaScriptであるが、Node.jsを使ったツールが開発されるようになると、これらを管理するバージョン管理システムの必要性が生まれた。 npmは、Node.jsのツールやパッケージ(モジュール)をインストールしたり管理したりするだけでなく、パッケージを扱うためにインターフェイスを備えている。リポジトリ機能も備えており、必要とするパッケージ(モジュール)の検索、ダウンロード、インストール、アップデートを行えたり、開発したパッケージ(モジュール)を他者に公開できたりする。 フリー百科事典『ウィキペディア(Wikipedia)』より クッ…長い…これもスタンドの仕業か…?ということで、自分の言葉でまとめてみます。 Node.jsはそもそも、「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」っていう発想から生まれたサーバサイドのJavaScript実行環境のことでした。 npmは、このNode.jsのライブラリやフレームワークを一括管理してくれる便利ツールです。PHPでいうcomposer、Rubyでいうgem、Pythonでいうpip、Goでいうglideなどと一緒ですね。 これらを踏まえて整理すると、手順1~3で私がやろうとしていたことはすなわち 「Node.jsのnpmを使ってJavaScriptのフロントエンドフレームワーク(の一種)であるVue.jsを、開発中のLaravelアプリに組み込むこと」 ということになります。一文でまとめると「なんだ当たり前じゃん」感が出ちゃうんですけど、フロントエンドのフレームワークであるVue.jsを、サーバサイド側から取り込んじゃうって、結構画期的なんですよね。わざわざ<script>...</script>タグ使ってフロントエンド側でCDN呼び出さなくてよかったり、したがってリクエスト数が減らせるといったメリットがあるからです。 ここで、見落としていたロジックに気付く 先ほど、Node.jsは「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」という発想から生まれたサーバサイドのJavaScript実行環境のことである、と書きました。そう、まさにこのNode.js発祥の原点こそが、私を混乱の渦へと引きずり込んだ犯人だったのです。 調べたところ、今回の文脈では、Node.jsは「サーバサイドJavaScriptの実行環境」ではなく、「クライアントサイドJavaScriptの開発環境」と考えるのが正しかったようです。 だって、よくよく考えてみたら私、サーバサイドの処理はJavaScriptじゃなくてPHPで書いてるもん。Vue.jsはフロントエンド開発のフレームワーク、Laravelはサーバサイド開発のフレームワークだもん。 サーバサイドJavaScriptの高速処理が実現したことによって、サーバサイドJavaScript自体のパッケージ(Node.jsフレームワークExpressなど)だけじゃなく、クライアントサイドJavaScript開発にも便利なパッケージが次々と誕生した、というのは確かに自然な流れですね。 この「自然な流れ」の部分がすっぽり抜けてしまうと、サーバサイドでJavaScript以外の言語を使用してる状況で「え、なんでNode.jsインストールしなきゃならんの?、npm?え?え?」てなことになってしまいます。 つまり、LaravelとVue.js連携において、サーバサイドにおけるNode.jsの役割はnpmを使えるようにするというただそれだけにあって、サーバサイドとフロントエンドではなお別々の言語、別々のロジックが働いている。ということが、Node.jsが一枚噛んだことによって見えなくなっていたんですね。 では、どうすればいいか Node.jsはクライアントサイドJavaScriptの「開発環境」であり、Vue.jsはフロントエンド開発のフレームワークである。ということは、必要なのはVue.jsの「実行環境」じゃあないか!!! JavaScriptで動くものを「作る」ための「開発環境」と、「作る」作業を効率的にする「枠組み」が揃っていても、それを実際に「動かす」ための「実行環境」がないと動くものも動かないからです。 で、その実行環境を構築してくれるのが、かのLaravel/uiだったんですね!! すげー爽やかな気分だぜ!!新しいパンツを履いたばかりの正月元旦の朝のように!! こちらはLaravelのパッケージなのでcomposerでインストールします。 $ composer require laravel/ui フロントエンドスカフォールドが生成されたので、Vueのスカフォールドをセットアップします。 $ php artisan ui vue --auth Vue scaffolding installed successfully. Please run "npm install && npm run dev" to compile your fresh scaffolding. Authentication scaffolding generated successfully. ついに… package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "bootstrap": "^4.0.0", "jquery": "^3.2", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "popper.js": "^1.12", "postcss": "^8.1.14", "resolve-url-loader": "^3.1.2", "sass": "^1.20.1", "sass-loader": "^8.0.0", "vue": "^2.5.17", "vue-template-compiler": "^2.6.10" } } ついに現れたああああああああああああ!!! 見える…見えるよお兄ちゃん…僕にもvueとvue-template-compilerという文字が… これでやっとnpmコマンドが使えるようになったね… $ npm install フッ、ここまできたらどんなエラーも貧弱、貧弱ゥ!! 頑張れ!私はここまでよくやってきた!私はできる子!そして今日もこれからも!私が挫けることは絶対にないんだ!モード に突入しました。 ここまできたらどんなエラーが返ってこようが恐れることはありません。 RunとかRunning以下のコマンドをそのまま打ち込めばいいだけです。 # Run npm install --save-dev resolve-url-loader@3.1.2 to resolve 1 vulnerability Additional dependencies must be installed. This will only take a moment. Running: npm install vue-loader@^15.9.5 --save-dev --legacy-peer-deps 準備が整ったら、最後にビルドします。 $ npm run dev VueのExampleComponentsも用意されました。 勝った…。 勝ったんだ…この戦いに…。 終わりに 今回はLaravelとVue.jsの連携にlaravel/uiを利用しました。が、Laravel8では2021/4/26現在、認証系推奨ライブラリがlaravel/jetstremあるいはlaravel/breezeに変更になっています。1年前の情報はもう既に古くなってる、みたいな変化の激しい世界ですが、この目まぐるしさもまたモダンフレームワークの妙だなあと感じます。 終始ふざけてしまって恐縮ですが、この記事を読んでLaravelないしNode.js、npm、Vue.jsの理解が少しでも深まったよ!という方が一人でもいたなら幸いです。ここまでお付き合いいただいた方、ありがとうございました! 参考 JavaScriptとCSSの足場:Laravel公式ドキュメント laravel/ui:GitHub npmのpackage.jsonと依存関係を理解しよう:bagelee Node.jsとはなにか?なぜみんな使っているのか?:Qiita Awesome Node.js : 素晴しい Node.js フレームワーク・ライブラリ・ソフトウェア・リソースの数々:Qiita npm入門:Qiita 「実行環境」と「開発環境」の違い:「分かりそう」で「分からない」でも「分かった」気になれるIT用語
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

お兄ちゃん、Laravel8とVue.jsの連携ってどうやるの?npmでなにをしようとしているの?バナナはおやつに入る?

概要 この記事は、Laravel8でVue.jsを連携利用しようとするも、事前準備段階で早々につまづいてしまった1人の少女の数奇な運命を綴る冒険談トラブルシューティング談です。基本的にポエムです。ご了承ください。なお、Node.jsの環境構築方法や「そもそもVue.jsって何?」の部分にはほとんど触れていません。ご承知おきください。 おいおいおい、おいおいおいおい、Vueなんて、どこにも書いていないじゃあないか より良いアプリケーションにはより良いUI/UXが必要。より良いUI/UXを実装するためにはモダンなフロントエンドフレームワークとの連携が不可欠だッ!ということでLaravelの技術書を参考にVue.jsのセットアップをしようとしていた時に、事件は起こりました。 技術書によると、セットアップの手順は以下の通り。 createしたLaravelアプリにはpackage.jsonファイルが標準で用意されている $ npm installコマンドでpackage.json内に記述されたパッケージ類を全てインストールする $ npm run devコマンドでLaravelアプリをビルドし、インストールしたVue.jsを実際に使えるようにする あーそーゆーことね、完全に理解した。「言葉」でなく「心」で理解できたよッ!これなら私にもできりゅっ!とトゥインクルトゥインクルしていたのも束の間、次の文を読んだ瞬間、私は身の毛もよ立つような恐怖の渦きを味わうのであった。 package.jsonのdevDependenciesに、使用されるパッケージがまとめられています。ここで、"vue"と"vue-template-compiler"が見えるでしょう。これらがvue.js利用のパッケージです。 ここで、私のpacakege.jsonを見てみましょう。こちらが私のpackage.jsonです。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } ここで、"vue"と"vue-template-compiler"が見えるでしょう。 あれ…見えないな…。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } "vue"と"vue-template-compiler"が見えるでしょう。 いいえ、見えません。 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } 見えるでしょう。(n回目) おいおいおい、おいおいおいおい、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } Vueなんて、ましてやvue-template-compilerなんて、 package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "postcss": "^8.1.14" } } どこにも書いていないじゃあないか!! これはまさか…スタンドの仕業ッ!? いやいやっ、落ち着け私。私はそんなにヤワな女じゃないわ。 1人海外旅行中にトイレ詰まらせた時だって、親にソシャゲへの多額の課金がバレた時だって冷静に対処したじゃない…!! それに比べたらこんなの屁のカッパ、ちゃーら、へっちゃらなんだからッ…!! 今回だって乗り越えるわ、登り切ってやるッ!!!!! そもそも、npmとpackage.jsonでなにをしようとしてるのか npmとは npmとは、パッケージ管理システムの一種。Node Package Managerの意。 Node.jsは、サーバ上で動作するJavaScriptであるが、Node.jsを使ったツールが開発されるようになると、これらを管理するバージョン管理システムの必要性が生まれた。 npmは、Node.jsのツールやパッケージ(モジュール)をインストールしたり管理したりするだけでなく、パッケージを扱うためにインターフェイスを備えている。リポジトリ機能も備えており、必要とするパッケージ(モジュール)の検索、ダウンロード、インストール、アップデートを行えたり、開発したパッケージ(モジュール)を他者に公開できたりする。 フリー百科事典『ウィキペディア(Wikipedia)』より クッ…長い…これもスタンドの仕業か…?ということで、自分の言葉でまとめてみます。 Node.jsはそもそも、「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」っていう発想から生まれたサーバサイドのJavaScript実行環境のことでした。 npmは、このNode.jsのライブラリやフレームワークを一括管理してくれる便利ツールです。PHPでいうcomposer、Rubyでいうgem、Pythonでいうpip、Goでいうglideなどと一緒ですね。 これらを踏まえて整理すると、手順1~3で私がやろうとしていたことはすなわち 「Node.jsのnpmを使ってJavaScriptのフロントエンドフレームワーク(の一種)であるVue.jsを、開発中のLaravelアプリに組み込むこと」 ということになります。一文でまとめると「なんだ当たり前じゃん」感が出ちゃうんですけど、フロントエンドのフレームワークであるVue.jsを、サーバサイド側から取り込んじゃうって、結構画期的なんですよね。わざわざ<script>...</script>タグ使ってフロントエンド側でCDN呼び出さなくてよかったり、したがってリクエスト数が減らせるといったメリットがあるからです。 ここで、見落としていたロジックに気付く 先ほど、Node.jsは「サーバサイドもクライアントサイドも同じ言語で書けたらみんなハッピーだよね」という発想から生まれたサーバサイドのJavaScript実行環境のことである、と書きました。そう、まさにこのNode.js発祥の原点こそが、私を混乱の渦へと引きずり込んだ犯人だったのです。 調べたところ、今回の文脈では、Node.jsは「サーバサイドJavaScriptの実行環境」ではなく、「クライアントサイドJavaScriptの開発環境」と考えるのが正しかったようです。 だって、よくよく考えてみたら私、サーバサイドの処理はJavaScriptじゃなくてPHPで書いてるもん。Vue.jsはフロントエンド開発のフレームワーク、Laravelはサーバサイド開発のフレームワークだもん。 サーバサイドJavaScriptの高速処理が実現したことによって、サーバサイドJavaScript自体のパッケージ(Node.jsフレームワークExpressなど)だけじゃなく、クライアントサイドJavaScript開発にも便利なパッケージが次々と誕生した、というのは確かに自然な流れですね。Vue.jsはこの後者にあたるのです。 この「自然な流れ」の部分がすっぽり抜けてしまうと、サーバサイドでJavaScript以外の言語を使用してる状況で「え、なんでNode.jsインストールしなきゃならんの?、npm?え?え?」てなことになってしまいます。 つまり、LaravelとVue.js連携において、サーバサイドにおけるNode.jsの役割はnpmを使えるようにするというただそれだけにあって、サーバサイドとフロントエンドではなお別々の言語、別々のロジックが働いている。ということが、Node.jsが一枚噛んだことによって見えなくなっていたんですね。 では、どうすればいいか Node.jsはクライアントサイドJavaScriptの「開発環境」であり、Vue.jsはフロントエンド開発のフレームワークである。ということは、必要なのはVue.jsの「実行環境」じゃあないか!!! JavaScriptで動くものを「作る」ための「開発環境」と、「作る」作業を効率的にする「枠組み」が揃っていても、それを実際に「動かす」ための「実行環境」がないと動くものも動かないからです。 で、その実行環境を構築してくれるのが、かのLaravel/uiだったんですね!! すげー爽やかな気分だぜ!!新しいパンツを履いたばかりの正月元旦の朝のように!! こちらはLaravelのパッケージなのでcomposerでインストールします。 $ composer require laravel/ui フロントエンドスカフォールドが生成されたので、Vueのスカフォールドをセットアップします。 $ php artisan ui vue --auth Vue scaffolding installed successfully. Please run "npm install && npm run dev" to compile your fresh scaffolding. Authentication scaffolding generated successfully. ついに… package.json { "private": true, "scripts": { "dev": "npm run development", "development": "mix", "watch": "mix watch", "watch-poll": "mix watch -- --watch-options-poll=1000", "hot": "mix watch --hot", "prod": "npm run production", "production": "mix --production" }, "devDependencies": { "axios": "^0.21", "bootstrap": "^4.0.0", "jquery": "^3.2", "laravel-mix": "^6.0.6", "lodash": "^4.17.19", "popper.js": "^1.12", "postcss": "^8.1.14", "resolve-url-loader": "^3.1.2", "sass": "^1.20.1", "sass-loader": "^8.0.0", "vue": "^2.5.17", "vue-template-compiler": "^2.6.10" } } ついに現れたああああああああああああ!!! 見える…見えるよお兄ちゃん…僕にもvueとvue-template-compilerという文字が… これでやっとnpmコマンドが使えるようになったね… $ npm install フッ、ここまできたらどんなエラーも貧弱、貧弱ゥ!! 頑張れ!私はここまでよくやってきた!私はできる子!そして今日もこれからも!私が挫けることは絶対にないんだ!モード に突入しました。 ここまできたらどんなエラーが返ってこようが恐れることはありません。 RunとかRunning以下のコマンドをそのまま打ち込めばいいだけです。 # Run npm install --save-dev resolve-url-loader@3.1.2 to resolve 1 vulnerability Additional dependencies must be installed. This will only take a moment. Running: npm install vue-loader@^15.9.5 --save-dev --legacy-peer-deps 準備が整ったら、最後にビルドします。 $ npm run dev VueのExampleComponentsも用意されました。 勝った…。 勝ったんだ…この戦いに…。 終わりに 今回はLaravelとVue.jsの連携にlaravel/uiを利用しました。が、Laravel8では2021/4/26現在、認証系推奨ライブラリがlaravel/jetstremあるいはlaravel/breezeに変更になっています。1年前の情報はもう既に古くなってる、みたいな変化の激しい世界ですが、この目まぐるしさもまたモダンフレームワークの妙だなあと感じます。 終始ふざけてしまって恐縮ですが、この記事を読んでLaravelないしNode.js、npm、Vue.jsの理解が少しでも深まったよ!という方が一人でもいたなら幸いです。ここまでお付き合いいただいた方、ありがとうございました! 参考 JavaScriptとCSSの足場:Laravel公式ドキュメント laravel/ui:GitHub npmのpackage.jsonと依存関係を理解しよう:bagelee Node.jsとはなにか?なぜみんな使っているのか?:Qiita Awesome Node.js : 素晴しい Node.js フレームワーク・ライブラリ・ソフトウェア・リソースの数々:Qiita npm入門:Qiita 「実行環境」と「開発環境」の違い:「分かりそう」で「分からない」でも「分かった」気になれるIT用語
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MySQLのLOAD DATA INFLEコマンドでファイルをインポートする

はじめに 担当している案件でMySQLで大量(10万件規模)のデータをinsertする必要があったため、 LOAD DATA INFILE コマンドでデータをインポートした際のナレッジや調査過程をまとめました。 案件で使用していたフレームワークがLaravelだったため、Laravel寄りのリンクが多くなっていますが、 他の言語/フレームワークでも、SQLを直接発行出来る機能があれば、代用は可能かと思います。 またMySQL以外でもOracleでも同様のコマンドがあるので、DBをOracleに変えた場合でも同じ実装は可能かと思います。 注意点 MySQLの起動オプションにlocal_infileを追加 MySQLの起動オプションにlocal_infileの設定を追加します。 以下のファイルに下記のように設定を追加してください。 /etc/mysql/conf.d/my.cnf local_infile=true mysqlコマンドの場合は上記のオプションを引数に追加して起動しましょう。 configファイルに追記した場合は、MySQLのサービスの再起動も忘れずに! デバッグ/エラー解析 LOAD DATA INFILE コマンドは、MySQL側のインポート機能を直接呼び出す仕組みのため、 SELECT文やINSERT文のSQLの発行時のようにアプリケーション側のログにエラー内容が出力されることがありません。 そのため、デバッグやエラー解析は困難を極めます。 インポート先のテーブル名やカラム定義、インポートするファイル名やファイルパス等は念入りに確認しておいた方が良さそうです。 意外にtypoしていたりすると、気付かずハマります(苦笑) 参考 LaravelでデータをDBに保存したいときのメモリ不足をなんとかする LaravelでLOAD DATA LOCAL INFILEできない Laravel ExcelパッケージでCSVデータをDBへ一括登録する方法 REPLACEとAUTO_INCREMENTを使用してLOADDATAINFILEを実行しようとしています 【MySQL】LOAD DATA INFILE でCSVデータをインポートしたい MySQLの「load data LOCAL infile」の「LOCAL」って何?どこ? MySQL LOAD DATA LOCAL INFILE で特定列を指定してインポートする
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CSRF(クロスサイト・リクエスト・フォージェリ)の危険性とその対策について

CSRF(クロスサイト・リクエスト・フォージェリ)とは CSRFを一言で表すと『Webサイトにログインしたユーザが悪意ある人間によってあらかじめ用意された罠によって、意図しないリクエストを送信されてしまう脆弱性』です。 被害者は脆弱性のあるWebサービスにログイン状態を保持したまま他サイトの掲示板等で悪意ある人によって投稿されたURLをクリックすると被害者が意図しない形で情報やリクエストが送信されてしまいます。 具体的な被害としてはログインしているWebサービスでの設定の変更(パスワードの変更など)、掲示板への不適切な内容の書き込みが気づかないうちに実行されてしまいます。 過去にCSRFの被害者が自分のIDで掲示板に殺害予告が書き込まれ誤認逮捕されてしまったケースもあるので恐ろしい脆弱性です… CSRFの対策 CSRFが起こってしまう原因は脆弱性のあるサイト(以後脆弱性サイトと呼ぶ)のリクエストが内部からなのか外部からなのかが判別されていないからです。 例えば脆弱サイトで名前を変更するために以下のようなHTMLが用意されていたとします。 <form action="change-name.php" method="get"> <label>新しい名前</label> <input type="text" name="name" value=""> <input type="submit" value="送信"> </form> 名前の変更処理はformタグのactionにあるようにchange-name.phpで行われるとします。 getで送信しているので名前に田中と入力して送信ボタンを押すとこのようなurlが生成され送信されます。 http://zeizyaku-site/change-name.php?name=田中 この脆弱サイトのchange-name.phpではユーザがログインしていたらこのname=田中をPOSTで受け取り名前を変更します。 しかし、問題なのはこのurlはサイトの外部からでも送信できてしまいます。 例えばある掲示板サイトに悪い人がこのようなURLを投稿したとします。 http://zeizyaku-site/change-name.php?name=バカ このname=バカとあることから、仮に掲示板のこのURLをクリックしたユーザが脆弱サイトにログインしていたら勝手に名前をバカに変更されてしまいます。 これは外部からのリクエストなのにかかわらず、脆弱サイトはその見分けがつかないためこの内容で実行されてしまいます。 なので対策としてはWebサイトがリクエストを内部からなのか外部からなのかをきちんと見分けをつけれるようにすることです。 そのためにはトークンというものを使用します。 トークンというのは簡単に言うとコンピュータ側が使用するパスワードみたいなもので「ワンタイムパスワード」と言うとイメージしやすいと思います。 このトークンはPHPならばsession_id()のような関数を使用します。自作でトークンを作成すると推測される恐れがあるので提供されている関数を使ったほうが安全です。 <?php // トークンを生成するコード session_start(); // セッションを開始すると自動でセッションIDが発行される $session_id = session_id(); // 現在のセッションIDを取得 echo $session_id; // 予測不能なランダムな値が表示される。 例:k12hc94du3tfubihqhip9leupl ?> session_id関数は引数を渡さずに呼び出すと現在設定されているセッションIDを取得できます。 トークンは予測不可能な値をサーバーサイドで生成して、それをHTMLフォームにhiddenで持たせておきます。 <form action="change-name.php" method="get"> <label>新しい名前</label> <input type="text" name="name" value=""> <input type="hidden" name="token" value="<?php echo session_id()?>"> <!--トークンを持たせておく--> <input type="submit" value="送信"> </form> トークン情報を一緒に送信して、サーバーサイドで名前の変更を行う前に設定されているセッションIDと送信されたトークンが一致するかを調べます。 <?php //change-name.phpでの処理 session_start(); // トークンのチェック if(session_id() === $_GET["token"]){ $name = $_GET["name"]; // 以下名前の変更処理をする } ?> このトークンは他の人間には知られることはまず無いため、外部からのリクエストで名前を変更することは不可能になります。 仮に先程の掲示板に貼られたURLの http://zeizyaku-site/change-name.php?name=バカ をクリックしてもトークン情報がないためこのリクエストは処理されません。 CSRFを防止するためにも必ずトークンを使用して、内部からのリクエストからしか受け付けないようにするようにしましょう。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

laravel タイムスタンプを無効にした(メモ)

使わない場合はエラーがでたりするため無効にしておいたほうがいい。 class User extends Eloquent { public $timestamps = false; //こいつを追加する }
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

M1 MacでPHP開発環境をDockerで構築する

M1チップ搭載のMacを使ってPHP開発環境をDockerで構築してみたいと思います。 やりたいこと ・ CentOS7のイメージからコンテナ作成 ・ Apache + PHPのWeb環境 ・ Macのローカルフォルダと、Dockerコンテナのフォルダ共有 ・ SSL通信ができること(httpsでアクセスできる) Docker インストール まずは「Docker Desktop for Mac」をインストールします。 こちらのページの「Mac with Apple Chip」からダウンロードできます。 https://docs.docker.com/docker-for-mac/install/ Rosetta 2も必要になるので、手順を参考にしてインストールしてください。 MacとDockerの共有フォルダ作成 Macのターミナルを起動して、Dockerコンテナと共有するフォルダを作ります。ACCOUNT_NAMEはご自身のMacアカウントと置き換えてください。 # Mac mkdir /Users/ACCOUNT_NAME/webroot Docker コンテナ作成 CeontOS 7のイメージからコンテナを作成します。ACCOUNT_NAMEはご自身のMacアカウントと置き換えてください。 # Mac docker run --privileged -it -p 80:80 -p 443:443 -v "/Users/ACCOUNT_NAME/webroot:/var/www/html" --name webserver centos:centos7 /sbin/init CentOS 時刻設定 「Docker Desktop for Mac」からコンテナのCLIボタンを押して、CentOSのコンソールを立ち上げます。 時刻を設定します。 # CentOS timedatectl set-timezone Asia/Tokyo Apache インストール Apacheをインストールします。 # CentOS yum install -y httpd Apacheを起動します。 # CentOS systemctl start httpd Macのブラウザからアクセスして、Apacheの画面が表示されればOKです。 http://localhost/ PHP インストール PHPをインストールします。標準では5.4のバージョンがインストールされるので、必要であれば他のバージョンをインストールします。 # CentOS yum install -y php インストール後はApacheを再起動します。 # CentOS systemctl restart httpd Macで作った共有フォルダにPHPの動作確認用ファイルを作成します。ACCOUNT_NAMEはご自身のMacアカウントと置き換えてください。 # Mac vi /Users/ACCOUNT_NAME/webroot/info.php 下記の内容を入力して保存します。 <?php phpinfo(); ?> PHPの動作確認用ファイルにアクセスします。 http://localhost/info.php PHPの設定が表示されればOKです。 SSL設定 httpsでアクセスできるようにcertbotをインストールします。インストールするだけで自己署名証明書が設定されます。 # CentOS yum install -y epel-release yum install -y certbot yum install -y certbot-apache インストール後はApacheを再起動します。 # CentOS systemctl restart httpd MacのSafariからhttpsでアクセスします。Chromeではキーチェーンの設定をしないとページが見れないので、Safariからアクセスします。 https://localhost/ 警告が表示されますので「このWebサイトを閲覧」から証明書を許可します。 ページが表示されればOKです。 補足 コンテナ起動時にApacheを自動起動する # CentOS systemctl enable httpd Apacheの設定ファイルの場所 # CentOS vi /etc/httpd/conf/httpd.conf PHPの設定ファイルの場所 # CentOS vi /etc/php.ini 最後に 最小限ですがPHPの開発環境を構築できました。あとはDBをインストールなど色々とカスタマイズしていきたいと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PHP5上級試験/準上級試験の上級合格に挑戦(22) 上級落ちました その2

結果は 先日が試験。 結果はタイトルの通り。 前が825点で、今回が875点。 うん、50点はあがってる。爆上げといかないのがきつい。 もちろん受かるまでチャレンジし続けるので、続ける。 ここまできたらもう受からないとお金がもったいない。(落ちるのももったいないんだけど) ただ、次で最後にしたいところ。お金もけっこうかかっているし。 今から申し込んでおく。 ひとまず、結果を見比べてみようと思う。 結果内訳 ↑が6個、→が8個、↓が5個と、↓が1つ多くなった。 3章〜13章で点が取れるようになっている。 ただ、問題集やマニュアルに解答がない、本質を聞く難しい問題もあるが、 それ以外でも取りこぼしが多かったので、やはり黒本を完全に暗記するということに尽きる。 たとえば、問題集の解答だけでなくて、選択肢のところを言い換えた問題というのはほぼ確実に出ている。 難しい問題はとにかくおいといて、取りこぼしのないように読み込みと暗記と理解をしっかり。 弱いところはしっかり集中して暗記をしていく。 とくに正解でない、選択肢のところも。 目次 出題割合 前回 今回 判定 1章 PHPについて 0 - - - 2章 PHP言語の基本 0 - - - 3章 関数 0.02 50% 50% → 4章 文字列 0.02 50% 50% → 5章 配列 0.04 33% 67% ↑ 6章 オブジェクト 0.1 33% 50% ↑ 7章 ウェブに関するテクニック 0.12 63% 88% ↑ 8章 データベース 0.08 40% 100% ↑ 9章 グラフィック 0.04 50% 50% → 10章 PDF 0.04 100% 100% → 11章 XML(&XML系で追加された関数) 0.06 100% 75% ↓ 12章 セキュリティ 0.12 43% 57% ↑ 13章 アプリケーションに関するテクニック 0.08 80% 40% ↓ 14章 PHPの拡張 0.04 0% 0% → 15章 WindowsでのPHP 0.02 50% 0% ↓ 予備 SPL(Standard PHP Library)/日付クラス/PEAR(管理系のコマンドなど) 0.04 50% 50% → 予備 名前空間/クロージャー/リフレクション/Late Static Binding 0.04 100% 0% ↓ 予備 JSON 0.02 100% 100% → 予備 PDOとネイティブモジュールの違い/mysqlndドライバについて 0.04 0% 0% → 予備 正規表現(pcre, posix, mbstring) 0.02 100% 0% ↓ 予備 APD/Xdebug/memcache 0.04 50% 100% ↑ 予備 フィルター 0.02 0% 0% → というわけで 今後の方針として、全体を復習しつつ、弱いところ、DB,ウェブに関するテクニック、セキュリティ、アプリケーションに関するテクニック、PHPの拡張、WindowsのPHP,SPL、名前空間、リフレクション、mysqlnd、正規表現、APD、フィルターについて頑張っていく PHP3版も確認したが、トレイトなど、載ってない問題はほぼ出ず、どっちかというと黒本の応用が多かったので、今後は黒本を中心に、取りこぼしのないようにしていく
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む