[Laravel]モデルとマイグレーション

福岡拠点の香月です。

前回はLaravelのプロジェクトを作成しました。
今回はこれにDBへのアクセス設定と、モデルの追加及びDBのマイグレーションを行います。

DBへのアクセス設定はアプリケーションのルートフォルダにある.envファイルで行います。この.envファイルは.env.exampleを元に作成されます。
開発環境、検証環境、本番環境でそれぞれ異なる設定なのでその環境ごとのファイル.env.develop、.env.staging、.env.productionを作成することになるでしょう。リリース時にはリリース環境にあったファイルを.envにリネームします。
※Laravelでは.envはソース管理に含めないことがガイドラインに書いてあります。これはプロジェクトのルートフォルダにある.gitignoreを見ても明らかです。

さて .env を編集する前に、アプリケーションで使用する mysql のユーザーを作成します。また、使用するDBを作成します。

1行目でmysqlにrootユーザーでログインします。
3行目でアプリケーションで使用するデータベースを「scoresheet」という名前で作成します。
4行目ではデータベース使用するユーザーとして「ss_user@localhost」を作成しつつ、必要な権限設定を行います。
5行目では山椒の実のユーザーを作成します。
6行目で権限を反映します。

これでDBの準備が整いました。
.env を開くと、DBに関する設定を行う場所があるのでここに情報を記載します。

※本当の設定箇所は config/database.php です。しかし環境ごとに異なるなので.envに記載し、database.phpからは.envを参照するようになっています。

DBへのアクセス設定ができたので、ここからはモデルの作成とテーブルを追加する作業、マイグレーションです。アプリケーションのルートフォルダで

を実行すると モデルクラス用のファイルが作成されます。-mオプションでマイグレーションファイルも一緒に作成されるので、モデルを作成するときは指定しましょう。

app\Score.php
database/migrations/<日付_時間>_create_scores_table.php

モデル名を複数形の「スネークケース」にしたものが、テーブル名として使用されます。「Score」は「scores」になります。Laravelは内部に辞書をもっており、英単語を適切に複数形にしてくれます。ネイティブじゃない私にはありがたい機能です。
あとはこれを編集して必要なフィールドを追加します。

これとは別にLaravelではプロジェクト作成時にusers、password_resetsテーブル用のマイグレーションファイルが作成されています。認証用ですね。
これと今作成したマイグレーションファイルのすべてが次のコマンドでまとめて
DBに登録されます。

「php artisan migrate:status」でマイグレーション結果を確認できます。

※一度もマイグレーションを実行していない状態で実行するとエラーが出てしまいます。

「migrations」というテーブルが無い!と怒られるのですが、このテーブルは最初にマイグレーションを実行したときに作成されます。これを知らずにちょっとはまりました。

モデル及びテーブルがもっと必要な場合は「php artisan make:model xxx -m」を必要なだけ繰り返しましょう。最後に「php aritisan migrate」を忘れずに。

プログラムはこのモデルを使ってデータにアクセスしていきますよー。

4K放送・8K放送仕様確認

前置き

現行ハイビジョンを超える超高画質を実現する、次世代の映像規格4K・8K。2018年12月1日から、4K放送・8K放送である「新4K8K衛星放送」が始まる。
参考(総務省)
番組表関連アプリ実装に伴い、番組表関連の仕様についての確認を実施。

確認

仕様は一般社団法人電波産業会(ARIB)にて規定されているが、無償公開はされていない。関連情報として、総務省が情報通信審議会の資料を公開している。
総務省 情報通信審議会情報通信技術分科会 放送システム委員会(第41回)
以下、TLVストリームを入手しておらず実環境未検証。考察レベルであり、認識違い誤記等あれば随時更新予定。

既存2K放送 4K放送・8K放送
方式 MPEG-2 TS MMT・TLV
ストリーム TSストリーム
TLVストリーム
放送局ロゴ HDラージ
HDスモール
SD4:3ラージ
SD4:3スモール
SD16:9ラージ
SD16:9スモール
2K
スモール
ラージ

※MH-EIT(MPEG-H Event Information Table)はEIT(Event Information Table)に規定されるテーブル、記述子と同機能を持つ。

結論

放送局ロゴの扱いは考慮する必要があるが、その他についてはMPEG-2 TS方式と同機能を持つ規定となっている。
ミドルウェアの対応指針にも依存するが、アプリで違いを意識する必要はない模様。

[Laravel] 値検査(バリデーション)について

福岡拠点の野田です。
秋雨や台風が気になりますが、過ごしやすい日々が増えてきたと思います。
今日は、Laravel の値検査の仕組みについて取り上げようと思います。

Laravel には値検査を行う設計の方向性として大きく3つの選択肢があります。
・FormRequest を継承してリクエストフォームオブジェクトを作る
・ValidatesRequestsトレイトを使う
・Validator ファサードを使う

FormRequestを作る場合

Controller に対して Illuminate\Foundation\Http\FormRequest 型のメソッドインジェクションを指定しておくとそのメソッドに対応するURLが呼び出された際に値検査がかかるという仕組みになります。バリデーションの結果が false の場合、リクエスト値をセッションに保存して、リクエストを投げた前のページに戻ります。

とても便利な仕組みですが、都度、FormRequestを実装することになります。毎回似たようなコードを書くのは煩わしいですよね。そこで以下のような基底クラスを作成して継承して使いまわすことにします。この基底クラスは、自分のクラス名からバリデーションの設定を読み込んで動作する仕組みで動いています。

以下は、config/validation.php の記述例です。FormRequest実装クラス名をキーに設定を記述するとそれを読み込んでくれる仕掛けになっています。クラスの型を利用しつつ、リクエスト値の検査は設定ファイルを利用してカスタマイズしやすくします。

さらにテンプレート側に目を向けてみましょう。入力フォームのテンプレートは、エラー表示と「戻る」ボタンで遷移の両方を共通で実現している場合がほとんどだと思います。Laravel で用意されている old ヘルパーメソッドで取得できるのは、エラー時のセッションしかありませんので、以下のような記述をすることでエラー時のセッション値があれば、セッション値、なければリクエスト値をとる実装が可能です(old メソッドのデフォルト値にリクエスト値を設定する実装になります)。

エラーを表示する場合は以下で対応できます。

$errors->has(‘email’)や$errors->count()などもよく使うメソッドだと思います。エラーは MessageBag というクラスで定義されていますので、以下を参考にしていただければ幸いです。

https://laravel.com/api/5.6/Illuminate/Support/MessageBag.html

ValidatesRequestsトレイトを使う場合

FormRequest の処理のうち Controller 側の処理を切り出したものが ValidatesRequest になります。
Controller で use ValidatesRequest をすることで Controller 中で $this->validate() メソッドなどが使えるようになります。

以下 Laravel マニュアルページより

値検査に失敗すると Illuminate\Contracts\Validation\ValidationException が発生し、FormRequest 同様、前のページに戻ります。validateをかけるタイミングを調整できるため、リクエスト値の前処理が必要な場面や FormRequest の作成をしたくない場合に使われると思いますが、Validator ファサードの選択肢もあるため、相対的に利用する場面は少ないと思われます。

Validatorファサードを使う場合

Validator ファサードを使えば値検査部分だけを部品化して値検査をすることが可能です。バッチ系で値検査を行うときは直に呼び出して使うことが多いと思います。例えばCSVインポートバッチの入力値チェックなどはこの Validatorファサードの出番です。

上記は、config/validation.php で設定を外だししている例です。個別実装することももちろん可能ですが、ある程度共通化できるところは共通化しておくと良いでしょう。

まとめ

なんだかんだいいましたが、場面場面に応じて最適な値検査の方法を選択して実装していくとよいでしょう。その中で特に伝えたかったことが「設定ファイル化」という部分になります。値検査(バリデーション)というプログラムの課題の中でconfig/validation.php にまとめておく、HTML部品という課題の中で config/form.php にまとめておく、アプリケーション設定として、config/const.php にまとめておく、などなどです。後で入力チェックをまとめるときに個別の実装をみなくてよいのは、大きな助けになると思います。まだの方は、実装時の良い習慣としてプログラムの課題の設定ファイル化を是非やってみてください。

補足

以下補足になります。入力、確認、完了のような遷移がある場合のルーティングのTIPSです。通常、入力画面は、GETリクエスト、それ以外はPOSTリクエストとしていると思います。つい忘れがちですが、保存ページについては、GETも受け付けて入力画面に逃がすとよいと思います。戻すときの遷移でリロードして、MethodNotAllowedのエラーが見えてしまうとちょっとカッコ悪いですよね。

[Python]拡張モジュールをWin Debug版DLLで試すとエラー

福岡拠点の香月です。

Windows環境で動作するPython3.6.6の拡張モジュールをC++で作りました。
開発ツールはVisual Studio 2015です。
早速作成した拡張モジュールのDebug版を使ってみようとPythonインタプリタを起動してモジュールロードしたんですが゙………

とこのようにエラーが発生してしまいました。インタプリタも強制終了しているようです。

これは拡張モジュールがDebug版なので、Pythonバイナリもデバッグ版を使う必要があります。python_d.exeがpython.exeと同じ場所にあるのでそれを使いましょう。
また、拡張モジュール名にも「_d」が必要です。Release版が「spam.pyd」ならDebug版では「spam_d.pyd」です。リネームで十分です。

このようにFatal Python Errorは発生せずに続行できます。
Debug版でのデバッグをあきらめて、Release版に無理やりデバッグ情報をつけてデバッグしていた方、是非これをお試しあれ。

これに気付く前にVisual Studio 2017のドキュメントで次のようなものを見つけていました。
https://docs.microsoft.com/ja-jp/visualstudio/python/working-with-c-cpp-python-in-visual-studio?view=vs-2017
以下抜粋

警告

デバッグ構成の場合でも [C/C++] > [コード生成] > [ランタイム ライブラリ] のオプションを常にマルチスレッド DLL (/MD) に設定します。これは、この設定がデバッグ以外の Python バイナリのビルドに使用されるためです。
マルチスレッド デバッグ DLL (/MDd) オプションを設定すると、デバッグ構成をビルドするときに、”C1189: Py_LIMITED_API は Py_DEBUG、Py_TRACE_REFS、Py_REF_DEBUG と互換性がありません” というエラーが表示されます。 さらに、ビルド エラーを避けるために Py_LIMITED_API を
削除すると、モジュールをインポートしようとしたときに Python がクラッシュします (後で説明しますが、クラッシュは DLL のPyModule_Create の呼び出し内で発生し、出力メッセージは “Fatal Python error: PyThreadState_Get: no current thread (Python 致命的エラー: PyThreadState_Get: 現在のスレッドがありません)” です)。
/MDd オプションは Python デバッグ バイナリ (python_d.exe など) のビルドに使われますが、拡張 DLL に対して選ぶと、やはり Py_LIMITED_API のビルド エラーになります。

でもこんなことする必要なく、python_d.exeを使うだけでOKですよー。