【Go】順リストを書く
概要
いまさらですが順リストを書く。 元ネタは改訂第4版 C言語によるはじめてのアルゴリズム入門。
本題
以下ソースコード。
old.pointer = n
の次にold = n
とあるのですが、これってoldの指すアドレスを変えるってことなんだな、と理解するまでに苦労した。オブジェクトとして考えてはいけない。
package main import ( "fmt" ) type node struct { name string tel string pointer *node } func main() { var head *node = new(node) var old *node = head for{ n := new(node) fmt.Println("name tel") fmt.Scanf("%s %s", &n.name, &n.tel) old.pointer = n old = n if(!next()){ show(head.pointer) break } } } func show(n *node) { fmt.Println("/////順リスト/////") for{ if(n == nil){ break } fmt.Printf("%s %s", n.name, n.tel) fmt.Println("") n = n.pointer } } func next() bool { continue_str := "" for{ fmt.Println("continue? [y/n]") fmt.Scanf("%s", &continue_str) if(continue_str == "y"){ return true } if(continue_str == "n"){ return false } } }
結果
name tel
と聞かれるので適当な文字列を半角スペース区切りで2つ入力する。
continueの旨を聞かれるのでy/nで回答。
yをすると、もう一度name tel
と聞かれる繰り返し。
nをすると作られたリストが表示される。
name tel a 1 continue? [y/n] y name tel b 2 continue? [y/n] y name tel c 3 continue? [y/n] n /////順リスト///// a 1 b 2 c 3
【Go】逆順リストを書く
概要
いまさらですが逆順リストを書く。 元ネタは改訂第4版 C言語によるはじめてのアルゴリズム入門。
本題
以下ソースコード。
package main import ( "fmt" ) type node struct { name string tel string pointer *node } func main() { var head *node = nil for{ n := new(node) fmt.Println("name tel") fmt.Scanf("%s %s", &n.name, &n.tel) n.pointer = head head = n if(!next()){ show(n) break } } } func show(n *node) { fmt.Println("/////逆順リスト/////") for{ if(n == nil){ break } fmt.Printf("%s %s", n.name, n.tel) fmt.Println("") n = n.pointer } } func next() bool { continue_str := "" for{ fmt.Println("continue? [y/n]") fmt.Scanf("%s", &continue_str) if(continue_str == "y"){ return true } if(continue_str == "n"){ return false } } }
結果
name tel
と聞かれるので適当な文字列を半角スペース区切りで2つ入力する。
continueの旨を聞かれるのでy/nで回答。
yをすると、もう一度name tel
と聞かれる繰り返し。
nをすると作られたリストが表示される。
name tel aaa 000 continue? [y/n] b continue? [y/n] y name tel bbb 111 continue? [y/n] n /////逆順リスト///// bbb 111 aaa 000
【Go】キューを書く
概要
いまさらですがキューを書きます。 元ネタは改訂第4版 C言語によるはじめてのアルゴリズム入門です。
本題
以下ソースコード。
package main import ( "fmt" ) const MAXSIZE = 5 // キューの最大長 var queue [5]int var head int = 0 // キューの先頭 var tail int = 0 // キューの最後尾 func main() { var n int = 0 for { fmt.Print("queuein(i) or queueout(o)?") var operator string fmt.Scanf("%s", &operator) if(operator == "queuein" || operator == "i"){ fmt.Print("number: ") fmt.Scanf("%d", &n) if(queuein(n) == -1){ fmt.Println("キューがいっぱいです") } } if(operator == "queueout" || operator == "o"){ if(queueout(&n) == -1){ fmt.Println("キューは空です") } } show() } } func queuein(n int) int { if(head != (tail + 1) % MAXSIZE){ queue[tail] = n tail = (tail + 1) % MAXSIZE return 0 } return -1 } func queueout(n *int) int { if(head != tail){ *n = queue[head] fmt.Println("out: ", *n) head = (head + 1) % MAXSIZE return 0 }else{ return -1 } } func show() { fmt.Println("/////current queue/////") for i, v := range queue { if(i == head){ fmt.Print("*") } if(i == tail){ fmt.Print("~") } fmt.Printf("%d ", v) } fmt.Println("") fmt.Println("") }
結果 *がついた部分はキューの先頭で、~がついた部分はキューの末尾。 queuein(i) or queueout(o)? と質問されるので、 queueinかiを入力すればキューに入れ、queueoutかiを入力すればキューから取り出すことができる。 queueinの場合はキューに入れる数値の入力を求められる。 queueoutの場合はキューから取り出した値を表示する。
queuein(i) or queueout(o)?i number: 1 /////current queue///// *1 ~0 0 0 0 queuein(i) or queueout(o)?i number: 2 /////current queue///// *1 2 ~0 0 0 queuein(i) or queueout(o)?i number: 3 /////current queue///// *1 2 3 ~0 0 queuein(i) or queueout(o)?i number: 4 /////current queue///// *1 2 3 4 ~0 queuein(i) or queueout(o)?i number: 5 キューがいっぱいです /////current queue///// *1 2 3 4 ~0 queuein(i) or queueout(o)?o out: 1 /////current queue///// 1 *2 3 4 ~0 queuein(i) or queueout(o)?o out: 2 /////current queue///// 1 2 *3 4 ~0 queuein(i) or queueout(o)?o out: 3 /////current queue///// 1 2 3 *4 ~0 queuein(i) or queueout(o)?o out: 4 /////current queue///// 1 2 3 4 *~0 queuein(i) or queueout(o)?o キューは空です /////current queue///// 1 2 3 4 *~0
【Go】スタックを書く
概要
いまさらですがスタックを書きます。 元ネタは改訂第4版 C言語によるはじめてのアルゴリズム入門です。
本題
以下ソースコード。
package main import ( "fmt" ) const MAXSIZE = 5 // スタックの最大長 var stack [5]int var sp int = 0 // スタックポインタ func main() { var n int = 0 for { fmt.Print("push(o) or pop(i)?") var operator string fmt.Scanf("%s", &operator) if(operator == "push" || operator == "o"){ fmt.Print("number: ") fmt.Scanf("%d", &n) if(push(n) == -1){ fmt.Println("スタックがいっぱいです") } } if(operator == "pop" || operator == "i"){ if(pop(&n) == -1){ fmt.Println("スタックは空です") } } show() } } func push(n int) int { if(sp < MAXSIZE){ stack[sp] = n sp++ return 0 } return -1 } func pop(n *int) int { if(sp > 0){ sp-- *n = stack[sp] fmt.Println("poped: ", *n) return 0 }else{ return -1 } } func show() { fmt.Println("/////current stack/////") for i, v := range stack { if(i == (sp - 1)){ fmt.Printf("*") } fmt.Printf("%d ", v) } fmt.Println("") fmt.Println("") }
使い方
push(o) or pop(i)?
でpushしたい場合はpush
かo
を入力、popしたい場合はpop
かi
を入力。
pushの場合はnumberが聞かれるので数値を入力する。
そうすると、現在のスタックの状態が表示される。
なお*
が付いている部分は現在のスタックポインタの位置。
popした際は、どの値がpopされたかを表示する。
出力結果
push(o) or pop(i)?o number: 1 /////current stack///// *1 0 0 0 0 push(o) or pop(i)?o number: 2 /////current stack///// 1 *2 0 0 0 push(o) or pop(i)?o number: 3 /////current stack///// 1 2 *3 0 0 push(o) or pop(i)?o number: 4 /////current stack///// 1 2 3 *4 0 push(o) or pop(i)?o number: 5 /////current stack///// 1 2 3 4 *5 push(o) or pop(i)?o number: 6 スタックがいっぱいです /////current stack///// 1 2 3 4 *5 push(o) or pop(i)?i poped: 5 /////current stack///// 1 2 3 *4 5 push(o) or pop(i)?i poped: 4 /////current stack///// 1 2 *3 4 5 push(o) or pop(i)?i poped: 3 /////current stack///// 1 *2 3 4 5 push(o) or pop(i)?i poped: 2 /////current stack///// *1 2 3 4 5 push(o) or pop(i)?i poped: 1 /////current stack///// 1 2 3 4 5 push(o) or pop(i)?i スタックは空です /////current stack///// 1 2 3 4 5
【Laravel】Eager-Loadingでlimitを使ってはいけない
概要
いけないというか、Eager-Loadingでlimitを利用する際は挙動をちゃんと理解していないと思わぬ動作をする。
本題
以下のようなテーブルがあった際に、Bookに紐づくChapterをEager-Loadingを利用して、それぞれの本の最後の章を取得したい場合を考える。
Books -------------- | id | name | |----|-------| | 1 | book1 | | 2 | book2 | | 3 | book3 | ------------- Chapters ------------------------------ | id | book_id | chapter_num | |----|---------|-------------| | 1 | 1 | 1 | | 2 | 1 | 2 | | 3 | 2 | 1 | | 4 | 2 | 2 | | 5 | 3 | 1 | ------------------------------
そのためにまず、Book-Chapterのテーブル結合を行う。
public function lastChapter() { return $this->hasMany(Chapter::class) ->orderBy('chapter_num', 'desc'); }
$books = Book::with(['lastChapter',])->get()
ここで、私は最後の章だけを取得したいが、現在のlastChapter
ではchapter_num
順に並び替えられているだけなので、
limit(1)
を付与すれば、各Bookの最終章を取れるのではないか、と考えたのでlimit(1)
を付与した。
public function lastChapter() { return $this->hasMany(Chapter::class) ->orderBy('chapter_num', 'desc') ->limit(1); }
しかしながら、limit(1)
を付与すると3つのBook中2つのBookのlastChapter
が空っぽだった。
ここで、Eager-Loadingの挙動について調べてみると、
Eager-Loadingによりlimit(1)
を付与する前のlastChapter
は以下のように変換される。
SELECT * FROM `chapters` WHERE `chapters`.`book_id` IN ('1', '2', '3') ORDER BY `id` DESC
なんと、内部的にはjoinしているのではなく、Chaptersのテーブルから含まれるBookのidをIN句で取得していた。 なるほど、ということはBooksとChaptersをjoinするのではなく、BooksとChaptersを別々に取得して 各Collectionオブジェクトを結合しているらしい。
そのため、limit(1)
を付与すると以下のクエリが発行されるが、Chaptersのデータが1行しか取れずに、
Booksの結果CollectionとChaptersの結果Collectionで結合できるのが1行のデータ分しか結合できないため、
3つ中2つのBookのlastChapter
が空っぽになるというわけだ。
SELECT * FROM `chapters` WHERE `chapters`.`book_id` IN ('1', '2', '3') ORDER BY `id` DESC limit 1
そのため、最終章を取得するためにはEager-Loadingは利用せずにクエリビルダーを使って最適なクエリを自前で記述するか、 Eager-Loadingを利用して最終章以外のデータも取得されてしまうが、それを受け入れて以下のように処理するのが良いだろう。
foreach($books as $book){ $book->lastChapter->first() }
【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オブジェクトを論理により操作することもまたコードの見通しを良くすることができる非常に強力な機能である。