Web日和

2023年6月9日金曜日

Responsive Viewer

レスポンシブデザインに対応するといくつもの解像度に対応する必要があります。

Google ChromeのDevToolsなどで解像度を変えられますが複数のサイズを確認するのは結構大変です。

それらを一度に確認することができるプラグインです。

Responsive Viewer

既存にあればそれを選択、なければサイズとタイプ（iPhone, iPad, Google Chromeなど）を入力して作ることもできます。

それらをまとめて確認できるので便利です。

PerfectPixel

デザインカンプを元にWebサイトを実装するわけですが、ぴったり合わせるのはなかなか難しいです。

PerfectPixelというプラグインがあります。

PerfectPixel by WellDoneCode (pixel perfect)

デザインカンプから画像として出力したファイルを読み込んでWebサイト上の上に重ね合わせることで、どれくらいズレているかはっきり分かります。

DevToolsで微調整すればリアルタイムで位置や大きさの調整が出来ます。

2023年5月18日木曜日

Webサイトを作成時に役立つGoogle Chrome拡張機能

Webサイト（フロントエンド）を作成していると、デザインカンプ通りに出来ているか色々確認したくなります。

それに役立つツールを検索してみました。
Google Chrome拡張機能として使うものです。

1. 画面上のオブジェクトの位置やサイズを知る

Designer Tools

以下のサイトで詳しい説明がされています。

「Designer Tools」の使い方：画像や任意の位置のサイズをピクセル単位で測定可能

2. オブジェクトの並びを知る

横方向や縦方向の並びを知るものです。

オブジェクト同士の位置関係を知るために画面上に線を引けます。定規ツールですね。

Grid Ruler

以下のサイトで詳しい説明がされています。

ブラウザ上でガイドを表示できる！ピクセル単位でのサイズ計測ができる！Chrome拡張機能「Grid Ruler」

3. フォント名やサイズを知る

WhatFont

Designer Toolsではフォントを含んだ箱のサイズしか分かりません。テキストのフォント名やサイズを知るためのツールです。

以下のサイトで詳しい説明がされています。

フォントサイズが分かる拡張機能「WhatFont」が便利だよ

4. 色の値を取得する

Webサイトで使っている色の値（カラーコード）を知るためのもです。

ColorZilla

2023年4月12日水曜日

PostgreSQLの日付フォーマット違いでCSVインポート時にエラー

日本から受領したCSVデータをローカルのPostgreSQLにインポートしたらなぜか

date/time field out of range "1/31/2022"

というエラーメッセージが、範囲外って言われても？

Error “date/time field out of range” occurs for MDY date style

えっ？

ひょっとして、 "31/1/2022"って書かないとダメってこと？

これが正解でした。

いやおかしい、私の環境では問題なく、他の担当の環境で発生しました。

同じPostgreSQLでバージョンも15なんですが？？？

釈然としませんが忘備録としてメモしておきます。

2023年4月10日月曜日

Laravel 自習 Model、マイグレーションファイルそしてシード

以前の記事でデータベースにアプローチする方法を記載しました。

DBクラス（クエリビルダ）: Controller内に記述します。
Eloquent(ORM) :Modelを生成して使用します。

MVCモデルを使って実装していきたいので、Eloquent(ORM)「エロクアント」の使い方について学んでいきます。

EloquentはORM(Object-Relational Mapping) です。

RDBのテーブルやレコードをPHPのオブジェクトのように扱うことが出来るようになります。

公式ドキュメントには以下の記述があります。

Eloquentを使用する場合、各データベーステーブルに対応する「モデル」があり、そのテーブル操作に使用します。Eloquentモデルは、データベーステーブルからレコードを取得するだけでなく、テーブルへのレコード挿入、更新、削除も可能です。

上記の通り、Eloquentを使用するには対象のテーブルに対応するモデルがあり、それに対して操作を行うとのことです。

また前回の記事にも書きましたが、モデル名はテーブル名に対応したものにする必要があります。

再度書いておきます。

テーブル名
別の名前を明示的に指定しない限り、クラスの複数形の「スネークケース」をテーブル名として使用します。

Modelの作成

とりあえずModelを作ってみます。

Userモデルを作ろうと思ったのですがなぜか最初から存在しています。
Productモデルを代わりに作成します。

$php artisan make:model Product

app/Models/Product.phpが以下のように生成されました。

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
    use HasFactory;
}

マイグレーションファイルの作成

【Laravel】マイグレーションのカラム(データ型)の種類まとめ！完全版

マイグレーションはデータベースのバージョン管理のようなもので、チームがアプリケーションのデータベーススキーマを定義および共有できるようにします。

上記の公式の説明があるようにデータベース特にテーブルのバージョン管理みたいなものです。開発中あるいは開発後でもバグ対応、仕様追加、パフォーマンスのためにテーブル構造は変わっていきます。

テーブルの変更を適用するためのSQL文を作成して実行しても構いませんが管理が大変になっていきます。

最初からテーブル構造のバージョン管理ができる機能があるのは便利ですね。

変更があってもレポジトリから最新のマイグレーションファイルを取得してartisanコマンドを実行すれば最新の状態になります。

実際にModel Productに対応したテーブルを作成するためのマイグレーションファイルを生成してみます。

$php artisan make:migration create_products_table

こんな感じでコマンドを実行するとdatabase\migrations/2023_04_10_075612_create_products_table.phpが以下のように生成されました。

<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     */
    public function up(): void
    {
        Schema::create('products', function (Blueprint $table) {
            $table->id();
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     */
    public function down(): void
    {
        Schema::dropIfExists('products');
    }
};

ただこれだけだと、idとタイムスタンプしかないので編集していきます。

プライマリーキーは、product_idにしました。以下のように設定します。

protected $primaryKey = 'product_id';

マイグレーションファイル

$php artisan migrate

を実行すると以下のようにテーブルが作成されました。

コマンド実行してテーブルを新規作成する

DBを確認すると以下のようにテーブルが作成されていました。

作成されたテーブル

シーダーを使った初期データ登録

https://readouble.com/laravel/10.x/ja/seeding.html

LaravelでSeederを使う方法！(初期データを登録する)

開発を行うに当たってマスターテーブルの初期データやテスト用のデータが必要となります。

Product用のシーダーを作成します。

$php artisan make:seeder ProductSeeder

を実行すると

database/seeders/ProductSeeder.phpが生成されました。

<?php

namespace Database\Seeders;

use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;

class ProductSeeder extends Seeder
{
    /**
     * Run the database seeds.
     */
    public function run(): void
    {
        //
    }
}

上記のようにrun()メソッドがあるだけです。

ここに初期データを記載していきます。Eloquentを使って１件のデータを作成してみます。

<?php

namespace Database\Seeders;

use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;
use App\Models\Product;

class ProductSeeder extends Seeder
{
    /**
     * Run the database seeds.
     */
    public function run(): void
    {
        Product::create([
            'product_name' => 'Test1',
            'product_price' => 100,
        ]);
    }
}

$php artisan db:seed --class ProductSeeder

を実行します。

想定したレコードがproductsテーブルに挿入されました。

設定したのは、”product_name”、”product_price” のみです。他のカラムは自動的に設定されました。

プライマリーキーも自動で１が設定されています。

2023年4月8日土曜日

Laravel 自習データベースにアプローチする方法

前回でアプリ用のDBの作成が終わりました。

DB用の接続情報を設定してからModelとマイグレーションファイルを作ってみます。

DB接続情報の記述

.envファイルの11 - 16行目がDB接続情報の記述欄です。

デフォルトでMySQLになっているので、DB名、ユーザ名、パスワードだけを修正すれば良いです。

.envファイルのDB接続情報

Modelの作成

フレームワークの中で直接SQL文を書くものもありますが、大体のフレームワークではテーブルを隠蔽してオブジェクトとしてプログラムから操作できる場合が多いですね。

ただテーブル間のリレーションがシンプルなら良いのですが、以前のプロジェクトでサブクエリとか使いまくって酷く歪なテーブルリレーションのプロジェクトに当たったことがあります。

思わず「テーブルの正規化とかスタースキーマとか勉強して出直して来い」って言いたくなるほどでした。そういうプロジェクトには適用しずらいでしょうね。

閑話休題

Laravelには２種類のデータベースにアプローチする方法があるようです。

DBクラス（クエリビルダ）

DBクラスを使う方法

https://readouble.com/laravel/10.x/ja/database.html

(Laravel) DBクラスとクエリビルダの違い・使い方

ただ、この機能はControllerの中で呼び出すみたいですね。

Controllerの中でDBクラスを呼び出して必要なデータを取得してから、Viewに渡して結果を表示する感じです。

use Illuminate\Support\Facades\DB;の機能です。

SQL文をそのまま書きます。

一般形は

$items = DB::命令文の種類('実際のSQL文', パラメータ);
実際のSQLの中に"：キー"という書式を埋め込むことができます。

これはSQL文中にある:idのように、あとからそこに値を割り当てるものでプレースホルダといいます。
後からくる値（パラメータで渡す）のために場所を取っておく感じです。
単なる値でも複数の値を配列で渡すこともできます。

例：

DB::select('select * from テーブル名 where id = :id', $id);
DB::insert('insert into テーブル名 (id, name) values (:column1,:column2)', $param);
DB::update('update テーブル名 set column1 = :column1, column2 = :column2' where id = :id, $param);
DB::delete('delete * from テーブル名 where id = :id', $id);

クエリビルダを使う方法

https://readouble.com/laravel/10.x/ja/queries.html

Laravel クエリビルダ記法まとめ

この機能もControllerの中で呼び出すみたいですね。

Controllerの中でクエリビルダを呼び出して必要なデータを取得してから、Viewに渡して結果を表示する感じです。

上記のDBクラスは直接SQL文が書けるので、SQL文が分かっている人にとっては便利でしょうね。
SQLクライアントを使ってSQL文を実行して想定した結果が得られることを確認してからソースコードにコピペして変数の部分だけパラメータ渡しにすれば良いです。

私的にはこれで全然問題ないのですが、

SQL文にパラメータの値を組み込んで最終的なSQL文を生成するので正しいSQL文が実行されているか分かりずらい。
渡す値によっては予想外のSQL文が実行される危険がある。
PHPでプログラムを書いているのにDBアクセスのところだけ別の言語で書かないといけないのはストレスになる。

といった理由でクエリビルダが生まれたようです。

DBクラスと違って直接SQL文を書くことはなく、必要なメソッドを呼び出してパラメータを渡すことでSQL文を生成してくれます。

なので最終的なSQL文は表面上には現れません。

use Illuminate\Support\Facades\DB;を使います。

DB::table(テーブル名)

でビルダ(\Illuminate\Database\Query\Builder)を取得します。

ビルダはSQLクエリ文を生成するための機能を提供します。

例：

DB::table(テーブル名)->get();
DB::table(テーブル名)->insert($param);
DB::table(テーブル名)->where('id', $id)->update($param);
DB::table(テーブル名)->where('id', $id)->delete();

対象のテーブルのビルダを取得して用意されてるメソッドを使って操作するのでSQL文の書き間違いは無くなるでしょうね。

ただクエリビルダで複数テーブルをジョインするような場合はどうするんだろう？

Eloquent(ORM)

EloquentはORM（Object-Relational Mapping）で「エロクアント」と読みます。
DBのテーブルやレコードをオブジェクトとして扱える仕組みです。

https://readouble.com/laravel/10.x/ja/eloquent.html

Eloquentを使用する場合、各データベーステーブルに対応する「モデル」があり、そのテーブル操作に使用します。Eloquentモデルは、データベーステーブルからレコードを取得するだけでなく、テーブルへのレコード挿入、更新、削除も可能です。

ようやくModelが出てきました。

モデルは通常app\Modelsディレクトリにあり、Illuminate\Database\Eloquent\Modelクラスを拡張します。make:model Artisanコマンドを使用して、新しいモデルを生成します。

$php artisan make:model モデル名

でモデルを生成できます。

１点注意が必要です。モデル名はテーブル名に合わせる必要があります。

例：

モデル名	テーブル名
Flight	flights
AirTrafficController	air_traffic_controllers

公式に以下の説明があります。

クラス名の複数形をスネークケースにしたものが自動的にテーブル名と見なされます。

これに適合しない場合はモデルのtableプロパティに設定します。

テーブル名
上記の例をちょっと見て、どのデータベーステーブルがFlightモデルに対応するかをEloquentに知らせていないことにお気づきかもしれません。別の名前を明示的に指定しない限り、クラスの複数形の「スネークケース」をテーブル名として使用します。したがって、この場合、EloquentはFlightモデルがflightsテーブルにレコードを格納し、AirTrafficControllerモデルはair_traffic_controllersテーブルにレコードを格納すると想定できます。

モデルの対応するデータベーステーブルがこの規約に適合しない場合は、モデルにtableプロパティを定義してモデルのテーブル名を自分で指定できます。

以下の気になる記述が公式にありました。

はっきり言って嫌いですね。下手なテーブル定義の温床です。

きっちりテーブル設計すれば、”id”なんていう主キーを定義する必要はないはずです。

これについてはアンチパターンとして議論がされているようです。

SQLアンチパターン「IDリクワイアド」の再検討

主キー
Eloquentは、各モデルの対応するデータベーステーブルにidという名前の主キーカラムがあることも想定しています。必要に応じて、モデルのprotected $primaryKeyプロパティを定義して、主キーとして機能する別のカラムを指定できます。

主キーについては、さらに下記の記述があります。

これは問題ないですね。PostgreSQLなどだと主キーにシリアルを設定して複数ユーザが同時にレコード挿入しても自動的にバッティングしない値になることが保証されています。

設計の都合上、非数値にしたい場合でも設定が可能です。

さらに、Eloquentは、主キーが増分整数値であることも想定しています。これは、Eloquentが主キーを自動的に整数にキャストすることを意味します。非インクリメントまたは非数値の主キーを使用する場合は、モデルにpublicの$incrementingプロパティを定義し、falseをセットする必要があります。

この記事では、モデルの作成、マイグレーションファイル作成、シードの作成まで行こうと思っていましたが長くなってきたので次の記事で書くことにます。