【Laravel】ファイルキャッシュが動くかテスト
概要
ファイルキャッシュを使って、1分経過したらキャッシュから消えるようにした。
方法
実際に、Laravelのドキュメントの通りに実装すると
/storage/framework/cacheの場所にキャッシュができていた。
$value = \Cache::store('file')->remember('key', 1, function() {
return DB::table('test')->get();
});
1分後にキャッシュが消えていることを確認すべく/storage/framework/cacheに作成された
キャッシュデータを確認したが、いくら待てども消えなかった。
なぜ消えないかはさておき、別の方法としてhasメソッドを使ってキャッシュの存在を確認してみた。
if (\Cache::store('file')->has("key")) {
// 存在する場合
}else{
// 存在しない場合
}
これを実行すると、1分後にキャッシュが存在しない場合のほうに処理が入ったので、とりあえずキャッシュは消えていそうである。
追記
不要なキャッシュを削除するためにはどうやらLaravelはキャッシュクリアコマンド(artisan)を利用する必要がありそう。
Laravelのアーキテクチャ
概要
自分的なLaravelの運用しやすいアーキテクチャ案ができたのでメモ。 細かい部分はプロジェクトによって異なると思うので、大枠的なアーキテクチャを述べる。
自分なりの考え
LaravelではMVCとしての開発の準備が充実しているため、MVCをベースとしたアーキテクチャーについて考える。
MVCはオブジェクト指向プログラミングではよく聞くWebアプリケーションの作り方であるが、Modelを効果的にデザインすることで見通しの立ちやすいコードを書くことができる。 Webアプリケーションは開発してそのまま、ということはなく機能拡張を行ったりパフォーマンスチューニングを行ったり、メンテナンスされていくものであるため、機能拡張や変更に対応していくことのできるアーキテクチャにすることが理想的である。 そのため、見通しの良いコードを書くことは機能拡張の際にも柔軟に対応することができるようになり理想に近づくことができる。
ところで、LaravelではMVCの開発の準備がされているものの、Laravel側としてはどういうMVCを構築してほしいのかを考えてみる。LaravelではControllerとViewを格納するためのフォルダは用意されている。しかしながら、Model用のフォルダは用意されていない。理由はMVCのMがどういうことをするか、どういう構成にするかは人によって異なるからである。人によっては論理操作やDB操作を単一のModelに全て押し込める人もいるだろうし、そうでない人もいるが私なりのModelデザインをこれからしていく。 一般的に、Modelで行ってほしいことは以下である。
- ビジネスロジック
- DB操作
なるべくControllerには無用に命令的なコードを書かずに、論理で追っていくことのできるスタイルが理想であると私は考えている。以降で「論理」という言葉が多用されるが、その意味は「処理を意味的なものにする」くらいに思っておいてほしいが、多分説明になっていないので下記のコードで説明する。足し算をする、というコードがあったとする。その際には、以下のように書く。
$a = 1; $b = 2; $result = a + b;
しかしながら、addというメソッドを用意することで以下のように書き換えることができる。
$a = 1; $b = 2; $result = add(a, b); // addメソッドはどこかで宣言されている
例のスケールが小さすぎるので何が嬉しいかはわかりにくいが、後者はaddメソッドによりaとbを足すんだな、と一目見ただけでわかる。このaddメソッドのように命令的な処理を関数化した、意味単位で処理のまとまりを「論理」と呼ぶことにする。
話をModelに戻す。Cotrollerではなるべく論理を利用してコードを書くために、命令的な部分(ビジネスロジックやDB操作)はModelとして水面下に隠されるべきである。
そのために、まずビジネスロジックはどのように水面下に隠すべきであるか。ビジネスロジックとはどういった存在であるかを考えると、単なる論理であるべきで、それ自身がオブジェクトになったりするものではない。そうしたことを踏まえるとphpにはtraitが使えるのでこれを使用する。traitのような論理を格納する場所はいまのところないので「Traits」や「Services」のような名前のディレクトリを作って、そこへ入れてあげれば良い。 これにより、オブジェクト指向でありながら関数型プログラミングのような論理によるコードを書くことができ、コードの見通しが立ちやすくなる。
. ├── Cotrollers │ └── UserCotroller.php │ ├── Services(Traitsでも良いと思う) │ └── UserService.php(UserTraits.phpでも良いと思う)
これでビジネスロジックはControllerから剥がすことができたので、次はDB処理の仕方を考える。 Laravelを利用しているのであればぜひEloquentを利用するべきである。 Eloquentでは以下のような記法でDB処理を行う(joinの例)。 我々がDBに対してjoin句を書く部分はhasOneメソッドにより論理的な操作ができるようになっている。
// 連携情報の宣言(論理の宣言)
public function foo()
{
return $this->hasOne('連携先テーブル名');
}
// 連携情報の宣言(論理の宣言)
public function foo2()
{
return $this-where('id' > 0);
}
// 上記の宣言を利用するためには次のようにする
$result = $this->first();
$result->foo();
$result->load(['foo2'])
// もしくは
$result = $this->with(['foo2'])->first();
これがEloquentの強みであるが、上記の一連のDB操作は大きく分けて「論理の宣言」と「利用」部分で分割することができる。 そのため、DB操作をさらに「論理」と「利用」に分けることで、DB操作の部分がごちゃごちゃしないスマートなアーキテクチャにすることができる。
これを実現するのにDBアクセスの処理をビジネスロジックから切り離す手法であるRepositroyパターンを使用する。 調べてみるとRepositoryパターンをLaravelで導入するQiita記事(これ)があるためこれを参考にして話を進める。
上記の記事では以下のような構成にしているので同じ構成にする。
.
├── Models
│ ├── User.php
│
├── Repositories
└── User
├── UserRepository.php
└── UserRepositoryInterface.php
さて、ModelsとRepositoriesの2つのディレクトリを作成することになるが、Modelsは論理を書く場所、RepositoriesはModelsで宣言されたレゴブロックを組み立てる場所として使う。 私の中でのルールはControllerからDB処理を呼び出すのはRepositoriesであり、原則Modelを直接呼び出さない。 中には、Repositoriesなんか必要なくてControllerに書けばよい、という人もいると思う。 確かにディレクトリが増えるし、概念も増えてしまっている。しかし、残念ながら全てのDB操作がEloquentで済まない場合があったり、DB操作をチューニングして高速にしたい場合、どのようにするか。もしRepositoriesがない場合はControllerかModelsにDB処理を書くことになる。 そうすると、ControllerもしくはModelsの役割がごちゃごちゃしてしまったり、Controllerが太ってしまったり残念なことになってしまう。
結果
MVCのMをService(トレイト)とRepository(レポジトリ)とModel(Eloquentの論理宣言)の3つに分かれたが、これにより各機能が意味的に分割され、更には処理を論理的な操作で可能にすることにより、見通しが立ちやすく、保守しやすいものになった(と思っている)。
(おまけ)Laravelのここが良い
しっかりとしたアーキテクチャを構成するために使いたいLaravelの機能。
Eloquent ORM
Eloquentを利用することで見通しの良いDB操作を行うことができる。
テーブル連携では以下のように記述することができる。
引数を省略すると、自モデルの'連携先テーブル名'_idと連携先テーブルのidが紐づけられる。
第二引数と第三引数を指定することで紐づけるキーを変更することができる。
例では1対1のテーブル連携であるが、メソッドを変えることで1対多や多対多の連携もできる。
Eloquentを利用することで、処理を論理的に記述することができソースコードの見通しが良くなる。
$this.hasOne('連携先テーブル名');
また、ミューテータも非常に便利である。以下のようにgetFooAttributeというメソッドを宣言すると、first_nameへアクセスする際データはucfirstメソッドを通した形で取得することができる。
つまりDBとModelの間に立つmiddlewareのような操作をさせることができる。
今回の例ではあまり実感はないが、nullの値は空白やデフォルト文字にすることができたり
金額は税率によって変わってしまうため、middlewareで税率を積算させることができるなど、様々な箇所で便利に使えるであろう。
public function getFirstNameAttribute($value)
{
return ucfirst($value);
}
これの逆パターンとして(getではなくset)も行うことができて、これをミューテータを呼ぶ。 例えば全部英子文字の入力を期待するが、大文字が入力された場合もミューテータを通すことにより小文字でDB登録することができる。
public function setFirstNameAttribute($value)
{
$this->attributes['first_name'] = strtolower($value);
}
更に、Eloquentを使用して終端メソッド(getやall)を利用した際はCollectionオブジェクトを取得することができる。
Collectionオブジェクトでは関数型プログラミング(のような手法)でmapやfilter等によりDBの取得結果に対して操作をすることができる。
Collectionオブジェクトを論理により操作することもまたコードの見通しを良くすることができる非常に強力な機能である。
ブラウザバック時にFORM送信された値が保持されない
概要
取り扱っているシステムでブラウザバック時にFORM送信された値が保持されない箇所があったので原因を調査した。
状況
選択肢1と選択肢2が存在し以下の流れでブラウザバックをする。
- 選択肢1の値はサーバサイドで作られる
- 選択肢1の選択に追従して選択肢2の値をXHR(Ajax等)で取得して変更する(初期表示の際は選択肢1の値を元にXHRでデータ取得をする)
- 選択肢2を選択する
- ブラウザバック
そうすると選択肢1ではFORMで送信した値が保持されるが、選択肢2では値が保持されない。 気づく人はこの時点でオチがわかるかもしれないが原因は以下。
原因
ブラウザバック時に選択肢1と選択肢2で選択した値が、前画面の選択肢1と選択肢2にセットされる。 選択肢1のデータはサーバサイドで作られるため、view上には選択肢1の収まるデータが存在するためブラウザバックしても値は保持される。 この際、選択肢2のデータリストは選択肢1の値をもとにXHRで取得されるため、選択肢2の初期のデータリストは空っぽである。初期状態の選択肢2のデータリストが空のため、ブラウザバック時に選択肢2が収まる場所がないため、選択肢2の値が消滅してしまう。
対策
- 選択肢2に入りうる値をサーバサイド側でviewに詰め込む
- 選択肢2の変更に追従するhiddenタグを用意する。選択肢2の値が変更されたらhiddenの値を利用して初期状態をセットしてあげる
MySQLを動かすことができない場合の対処方法
概要
以下のエラーが発生したためメモ。
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
詳細
mysql起動
「mysql」コマンドを実行しても上記のエラーが発生して先に進まない
service mysql start
エラーログをみる
エラーログは以下の場所へ出力されている。
/var/log/mysql/error.log
エラーログを見てみるとソケットファイルを作成できなかったとわかる
Could not create unix socket lock file /var/run/mysqld/mysqld.sock.lock.
mysqlユーザに権限を与える
ソケットファイルが作れるようにmysqlユーザに権限を与える
sudo chown mysql:mysql /var/run/mysqld
以下のコマンドで動かせばOK
service mysql start
【Python】oduleNotFoundError: No module named '__builtin__'
概要
以下のエラーが発生したためメモ。Python3では__buildin__が利用できない。
ModuleNotFoundError: No module named '__builtin__'
解決策
__buildin__の代わりにbuiltinsを利用する。
# import __builtin__ ※これは使えない import builtins
# __builtin__.__import__(引数) ※これは使えない builtins.__import__(引数)
【Python】Python3でnew.instancemethodが使えない
概要
以下のエラーが発生したためメモ。
ModuleNotFoundError: No module named 'new'
調べてみるとPython3ではnewモジュールが利用できないみたい。
解決策
以下のように行うことで、解消できる。
# import new ※これは使用できない from types import MethodType as instancemethod
# new.instancemethod(いくつかの変数) ※これは使用できない instancemethod(いくつかの変数)
