ターミナルからMySQLを終了するとき、quitコマンドとexitコマンドの両方ともで終了できる。これらのコマンドの挙動にはどの様な差があるのか気になったので、ドキュメントを当たって調べてみることにした。
下記のドキュメントを元に2つのコマンドの差を調べた。
https://dev.mysql.com/doc/refman/8.0/ja/mysql-commands.html
上記のドキュメントには、quitコマンドは下記の様に書かれていた。
Quit mysql.
文字通り、mysqlを終了するコマンドの様だ。
一方で、exitコマンドは下記の様に書かれていた。
Exit mysql. Same as quit.
「Same as quit」とのことで、quitと同じ挙動をする様だ。
mysqlを終了するコマンドが2つあって、両方とも同じ挙動をする、という結論に至った。
エンジニアなら普段Webサイト制作やWebアプリ開発をしていていると、ブラウザにキャッシュが残っているせいで自分が加えた変更が正しいのか確認がしづらいことはないだろうか。
そのときはブラウザのキャッシュを削除すればOKなので、今回はその方法をご紹介します。
MacBookでChromeをお使いの方は下記を参考にしてみてください。
皆さん、お疲れっす。すなです。
今回は私が最近知ったMacBookのアプリ「MouseCatch」（有料・¥300）をご紹介しようと思います。
これ、何ができるようになるアプリかというと、ショートカットキーを押すことでマウスをモニター間で移動させることができます。
私は職場でも家でもモニターがあるので、ノートPCのモニターと外付けの外部モニターの2画面で作業しているのですが、いつも薄ら感じていたモヤモヤが、
マウスをモニター間で移動させるとき、トラックパッドでわざわざ移動させるの面倒くさいなあ
と感じていました。
そこで出会ったのが、この「MouseCatch」（有料・¥300）でした。
https://apps.apple.com/jp/app/mousecatch/id1625127067
これは何ができるかというと、それぞれのモニターに自分で登録したショートカットキーを叩くことで一瞬でマウスがモニター間を移動できるようになります！
試しにやってみましょう。
僕がそれぞれのモニターに登録したショートカットキーは下記です。
実際にショートカットだけでマウスが移動する様子を見てみましょう。
最初は外部モニターにあるマウスですが、
この状態でshift + option + ↓を押すと、マウスが下のノートPCに移動しました。
更にこの状態でshift + option + ↑を押したら、マウスが上の外部モニターに移動しました。
ただ問題点として挙げるなら、ショートカットキーでマウスが移動したとしてもフォーカス（？）が直前のモニターに残ってしまいます。
フォーカスが直前の画面に残ってしまっているので、モニターAからモニターBに移動してきて、モニターBでなんらかのキーを押すと、モニターAの方でそのキーが反応してしまいます。
まあ、これについてはトラックパッドでマウスを移動させてた頃にも起きてた現象なので、ショートカットキーで移動したら、一旦画面のどこかをクリックする的な操作は必要かもですね。
上記で問題点を一応挙げましたが、個人的にはわざわざトラックパッドに手を移動させなくても済むようになったので、僕はだいぶハッピーになりました^ ^。
おしまい。
今日もWebサイト制作周りのことをつらつら。
今回は見出しにある通り、paddingとmarginの使い分けについてお話したいと思います。
Webサイト制作などでHTML&CSSを触るときに必ず遭遇するこのpaddingとmarginという概念。
これが慣れるまでは中々イメージが掴めなかったり、思ったように余白を調整できなかったりします。
この記事を通して、今回はpaddingとmarginの感覚を掴んでいただけたらな思います。
そして、もっと余白が扱うのが上手になっていただけたらなと思います！
もういきなり答えみたいな、今回の記事で僕が1番伝えたいことを初っ端に書いちゃうんですけど、僕は
paddingとmarginを「皮下脂肪」と「ダウンジャケット」
だと捉えています。
これだけで理解できた方は、もう完璧なので早速パソコンを開いて作業を続けてください（笑）
もう少し具体的に説明します。
要素自体にはそれ本来の大きさがあります。
文字だったり、画像自体の大きさだったり。
ただ、皮下脂肪（=padding）か多すぎるせいで本来の大きさ以上に膨れ上がって、皮膚（=border）が大きく膨れ上がります。
その結果、その要素の範囲はそのborderまでが範囲となります。
一方で、皮下脂肪（=padding）は全くなくてもダウンジャケット（=margin）を着ているせいで、皮膚（=border）の外側に範囲が増えていくパターンもあります。
皮下脂肪（=padding）は皮膚（=border）の内側なので、他の要素と重なり合わないです（体内なので？）。
一方で、ダウンジャケット（=margin）は他の要素のダウンジャケット（=margin）同士で重なり合うことができます（皮膚の外なので？）。
このイメージさえ掴めれば、paddingとmarginの違いはかなり理解しやすくなると思います。
皆さんも引き続き、勉強を続けましょう！
ある機能を実装していた。
途中である変数の状態を表すのに真偽値を返す関数を作ることにした。
皆さんは真偽値を返す関数を作るとき、どのように返す方が好みですか？？
<?php
/**
* 正常な入力値かどうかを検証する
* 引数の先頭と末尾にスペースが含まれないかを検証して、その結果を真偽値で返す。
* 今回の機能では、スペースがないことが望ましい。
*/
function check_is_space_included(string $input): bool
{
$first_letter = substr($input, 0, 1);
$last_letter = substr($input, -1, 1);
// パターン1
// デフォルトでfalseを返すようにして、もしどちらかにスペースがあったらtrueを返す。
if ($first_letter === " " || $last_letter === " ") {
return true;
}
return false;
// パターン2
// スペースが含まれるかどうかをそのまま戻り値として返す。
return $first_letter === " " || $last_letter === " ";
}
$is_space_included = check_is_space_included($input);
echo $is_space_included; // trueまたはfalseパターン1の方が関数の中身が直感的に理解はしやすいかなと感じる。
一方でパターン2は少し分かりにくいが、パターン1と同じ処理をたったの1行で表現できる綺麗さも感じる。
この場合、皆さんはどちらで戻り値を返す派とかありますか？？
今回はURLに変数を埋め込む「ルートパラメータ」の使い方を解説します！
座学よりも前に早速実践の中で使い方を見ていきましょう。
今回はゴールとして会員登録しているあらゆるユーザーのプロフィール画面を表示することを目標にします。
（今回は事前にユーザーのデータを10件Seederで作成してあります。）
最初にダメな例として静的な方法をご紹介して、後から理想的な方法をご紹介いたします。
まずは実際にプロフィール画面を表示するbladeを作成します。
ファイル名はusers.blade.phpにします。
ファイルの中身はこんな感じにするとします（めっちゃ質素です汗）
次にプロフィール表示用のControllerを作成します。
ユーザーについてのControllerなので、ファイル名はUsersControllerにするとします。
シェルで以下のartisanコマンドを実行してControllerを新規作成します。
$ php artisan make:controller UsersController
// 以下のようなメッセージが表示される
INFO Controller [app/Http/Controllers/UsersController.php] created successfully.「プロフィール画面を表示する」ので、メソッド名はprofileにします。
最後にbladeを表示したいのでviewを返すようにします。
ここまで以下。
まずはID番号が1のユーザーのプロフィールを表示したいのでModel経由でID番号が1のModelを取得してViewに渡します。
最後にこれを表示するためにroutesを作成していきます。
/users/1でID番号が1のユーザーのプロフィール画面を表示することにします。
準備ができたので、それでは実際にlocalhost/users/1にアクセスしてみましょう！
以下のような画面が表示されていると思います。
1人目のプロフィール画面は表示することができました。
それでは2人目、3人目、アプリケーションのユーザーが増えて10000人目のユーザーはどうやって表示したらいいでしょうか？？
web.phpに/users/1から/users/10000まで10000行のコードを書くのは馬鹿げていますし、ユーザーが増えたら都度web.phpを更新する作業も面倒なのは自明です。
こんなときは「ルートパラメータ」を使いましょう！
要はURLの最後の1の部分だけが変わって、それ以外の処理は基本的に共通なので、ID番号の部分(今回の例で言うと1の部分)だけ変更しましょう。
（やっと本題に入ります笑、たくさん勉強してLaravelスキルを身につけましょう！）
まずはweb.phpのroutesを編集します。
以下の画像にある通り、今まで/users/1だったURLを/users/{id}に変更しました。
（※最低限の理解のためにルートモデルバインディングは今回はしません。）
UsersControllerも編集します。
以下の画像のように、profileメソッドに先ほどweb.phpに追加したURLと同じidという名前の変数を引数に取ります。
この$idの中身は何なのでしょうか？？
中身を確かめるためにLaravelの開発でお馴染みのddメソッドを以下の場所に追加して、$idの中身を確認してみましょう。
この状態で再度localhost/users/1にアクセスしてみましょう。
画面には「1」と表示されました。
次はURLにlocalhost/users/2と入力してみると、どうなるでしょうか？
今度は画面に「2」と表示されました。
察しが良い方はお気づきかもですが、ddメソッドにはlocalhost/users/xxxの「xxx」の部分に入れた文字が表示されています。
localhost/users/3と入力すれば「3」と表示されますし、localhost/users/100と入力すれば「100」と表示されます。
（ちなみにlocalhost/users/helloと入力すれば「hello」と表示されますし、localhost/users/お疲れ様ですと入力すると「お疲れ様です」と表示されます笑）
これはどういうことかと言うと、web.phpで/users/{id}と入力したと思いますが、この{id}の部分はURLの/users/xxxの「xxx」の部分が反映されています。
「xxx」の値はそのままprofile($id)の$idの部分に渡されて、今回はそれをそのままddメソッドで出力していました。
つまりlocalhost/users/xxxと入力すると、profile($id)の$idには「xxx」が入るので、ここからはそれを使って取得するユーザーを自在に変えていきましょう！
以下の画像のように、$idを使って取得するユーザーを変更しましょう。
この状態でlocalhost/users/1を表示してみてください。
次はコードを何も変えずに、localhost/users/2を表示してみましょう。
この状態にすればID番号が3だろうが4だろうが、10でも1000でも、なんでも表示することができます。（厳密にいえば、localhost/users/xxxの「xxx」が数字だったらですが）
冒頭にあった以下の問題も解決することができます！
それでは2人目、3人目、アプリケーションのユーザーが増えて10000人目のユーザーはどうやって表示したらいいでしょうか？？
web.phpに
/users/1から/users/10000まで10000行のコードを書くのは馬鹿げていますし、ユーザーが増えたら都度web.phpを更新する作業も面倒なのは自明です。
これで皆さんも便利はLaravelライフを過ごしてくださいっ！！！！
Laravelで一部、こっちが指定した情報でデータを作成してほしいことがあったので、Factoryに例外を作成する方法をご紹介します。
今回は「メール確認が終了していないユーザーを作成する」という趣旨で作成します。
Factoryファイルのdefinitionメソッドを普通に埋めた後に、新しくメソッドを作成しましょう。
名前は分かり易ければなんでもOKです👍
public function email_not_verified()
{
return $this->state(function (array $attributes) {
return [
'email_verified_at' => null
];
});
}作成した例外のFactoryを実行しましょう。
通常のFactoryは以下のコマンドでSeederから実行します。
// 複数個作成するときはnのその数を入力する（1個のときは空でOK）。
User::factory(n)->create();これを先ほど作成した例外バージョンで実行する方法は以下です。
User::factory()->email_not_verified()->create();factoryメソッドを呼んで、createメソッドで実際に作成する前に、例外のメソッド（今回で言うとemail_not_verifiedメソッド）を間に噛ませてあげるとその例外が作成できます👍
上記を書いたあとはSeederを実行してください。（下記の例だとDBのレコードは全部リセットされます）
php artisan migrate:refresh --seeder必ずしもどちらか一方しか実行できないわけではなくて、もちろん両方とも同時に実行できます。
何を言っているかと言うのは、以下のコードを見たら分かると思います。
<?php
namespace Database\Seeders;
use App\Models\User;
use Illuminate\Database\Seeder;
class UserSeeder extends Seeder
{
/**
* Run the database seeds.
*
* @return void
*/
public function run()
{
User::factory(10)->create();
User::factory()->email_not_verified()->create();
}
}これをすると、通常のユーザーが10個と、メール確認が終了していないユーザーが1個作成されます。
Laravelで開発していて、SeederとFactoryの使い方でこんがらがったので、整理しました👍
以下は新しく作成するときに必要なファイルです。
上記4枚のファイルをartisanを使って簡単に作成する方法があります。
php artisan make:model Sample -msfartisanでmodelを作成します。
「-」でオプションを付与できるのでmigrationのm、Seederのs、Factoryのfを付与します。
それぞれのファイルに書く内容は以下です。
$fillableを作成した方がいいです👍
テーブルの定義を書く。
実行するFactoryファイルを追加する。
実際に作成したいテストのデータを書く。
fakerを使用するのが一般的と思われる。
上記の内容に加えて、Seederを司る大元のファイルであるDatabaseSeederに今回で作成したSeederファイルを登録しましょう。
<?php
namespace Database\Seeders;
use Illuminate\Database\Seeder;
class DatabaseSeeder extends Seeder
{
/**
* Seed the application's database.
*
* @return void
*/
public function run()
{
$this->call([
SampleSeeder::class
]);
}
}migrationファイルでデータを格納する受け皿を用意しました。
Modelを作成して、生成するデータの雛形を作成しました。
Factoryファイルで雛形を具体的に書きました。
Seederファイルでその雛形を実際に作成します。
以下のコマンドを実行してください。
php artisan migrate:refresh --seedmacOSで以下のコマンドを実行すると、Docker上で起動するLaravelアプリがインストールされる
curl -s "https://laravel.build/example-app" | bashコマンドないの「example-app」の箇所を任意のアプリ名に書き換える。
Formのバリデーションを管理するのに便利なRequestコントローラなるものがある。
今回はそれを扱う。
以下のartisanコマンドを実行すると、form requestを作成することが出来る。
php artisan make:request StorePostRequestこのコマンドを実行すると、StorePostRequest.phpファイルがapp/Http/Requestsディレクトリに作成される。
※app/Http/Requestsディレクトリがない場合は、make:requestを実行した時点で自動的に生成してくれる。
このRequest.phpファイルには、あらかじめauthorizeメソッドとrulesメソッドが用意されている。
先に説明だけすると、authorizeメソッドはリクエストを送ったユーザーがリクエストを実行する権利を持っているかを判断して、rulesメソッドはデータに適用する検証ルールを返す。
どんなユーザーがリクエストを実行できるかを判断する。
デフォルトではreturn falseのみ書かれていて、誰もリクエストできない状態になっている。
ここをreturn trueにしたり、他の処理を加えて、誰ならリクエストしていいかを制御できる。
rulesメソッドではルールの配列を返す必要がある。今までcontrollerに書いていたバリデーションをこのRequestコントローラに別で書くことができる。
これらの使い方は、バリデーションが必要なリクエストがきた時に引数に加える。
以下がサンプル。
use App\Http\Requests\StorePostRequest;
public function store(StorePostRequest $request)
{
// ここに処理を書く。
// 引数にStorePostRequestを書いてるから、ここに処理が走ってる時点でバリデーションをクリアしてる
}ちなみに、これらのバリデーションにひっかかったときは、controllerは自動的に前の画面に遷移してくれるから便利。
他のページに遷移させたいときはredirect()を使って、別途処理を書く必要がある。
またmessagesメソッドを加えて、エラーのときのフラッシュの文言を追加することが出来る。
結論、めちゃ便利。