スイーツ（笑）と呼ばないで!!

前回、urlやactive-urlのvalidation ruleを軽く紹介しながら、
「Validatorのソースを読もう!!」と呼びかけたわけだけれども、
ついでなので、emailのvalidation ruleについても触れておきます。

emailのvalidation ruleはソースを見ると内部的には

filter_var($value, FILTER_VALIDATE_EMAIL)

これを呼んでいる。

実はこの

FILTER_VALIDATE_EMAIL

はRFC 822の形式かどうかをチェックする。

ここで思い出さなきゃならないのは、ドコモが2009年3月までRFC違反でやっていた独自仕様だ。

ドットを複数回連続させることができたり、
アットマークの前にドットを使うことができたりする例のあれである。

完全に廃止されたわけではなく、新規登録では受け付けなくなった、というのが正確なところ。

よって、日本の6年以上前のドコモのメールアドレスを想定するなら、
このvalidation ruleではダメだということになる。


さて、ここまでくると、「なんだよ、laravelのvalidation使えねー」とか思うかもしれない。
でもそれは間違い。

alpha、array、in、numeric…….その他ほとんどのruleはそのまま使える。

ただ、一部のruleは注意が必要、というだけ。

例えば、前回のurlだって、webサイトの形式チェックしたいだけなら、その後に

「httpまたはhttpsで開始するか」

という正規表現を使ったvalidation ruleを追加すれば良い。

laravelにはregexという正規表現を使うためのvalidation ruleがある。
引数として正規表現をとれる。最強だ。

じゃ、どんな正規表現渡せば良いの？となるとやはりソースを読む。
preg_match($parameters[0], $value)
という感じでpreg_matchに引数としてそのまま渡す感じ。

とすると、マルチバイトの時とかちゃんと考えないといけないですね。
末尾に「/u」つけたりとか。
ただ、たまに日本語とかマルチバイト文字例は「/u」と覚えている人いますが、
このuはUTF-8のuです。Shift-JISとかEUC-JPとかそのまま渡しちゃダメですね。
じゃ、mb_eregに渡してあげればうまくやってくれるかというと、
これ、内部的にはmb_regex_encodingで指定の文字エンコーディングを使用します。
この関数のchang logを見ると、

Changelog

Version Description
5.6.0 Default encoding is changed to UTF-8. It was EUC-JP Previously.

と書いてありますね。最新のPHP5.6ではデフォルトがEUC-JPからUTF-8に変更されています。

この辺はとってもとっても複雑ですねー。
私も正直勉強不足ですし、できれば専門のプログラマに任せたい領域です。
(だから、あまり私の言うこと信じないでくださいねー　笑)

もし、あなたが駆け出しのPGで一芸に秀でて皆の役に立ちたいという志をもっているのなら、
この正規表現やvalidationの技術を極めてみてはいかがでしょうか？

私が新人の時には、その時点の先輩方の得意分野を考慮の上、先輩方が得意でない分野の1つを専門として担当しました。駆け出しの新人でもその分野については先輩方もプロフェッショナルとて敬意を表してくれますし、入社数ヶ月で何年も実務経験のある何百人もの前でその分野の講義をしたりもしたものです。

最後に、正規表現をいろいろ試せる便利なサイトを紹介して終わります。
http://www.regexr.com/
選べるフラグも限られているし完全ではありませんが、
基礎を学ぶには十分かと思います。

いつか正規表現にめっちゃくちゃ詳しくなったあなたが、
私のプロジェクトにアサインされる日を心待ちにしております。
(誰へのメッセージ?このブログ、読者いないけど 笑)

[0回]

• プログラミング
• COMMENT：0

前回、Form Request Validationについて書きました。

その中で、rulesメソッドに、例えば

public function rules()
{
　return [
　　‘title’ => ‘required|between:3,100’,
　　‘body’ => ‘required|min:10’,
　　'url' => 'required|url'
　];
}

こんな感じに書くとvalidationが簡単に書けることを紹介しました。

これは

・titleは必須で3文字以上100文字以下
・bodyは必須で10文字以下
・urlは必須でURLの形式

とかって意味になります。

超、簡単ですねー。

でも、何か気になりませんか？

URLの形式ってなんでしょう？

URLの形式チェックなら

◯　http://abc.com
◯ https://abc.com/def.html
☓　ttp://abc.com

なんとなく、無意識にこんな動きを期待しませんか？

でも、実は先頭のhが足らない

ttp://abc.com

はvalidationを通過します。

それどころか

hello://abc.com

とかでも通過してしまいます。つまり「:」の前は何でもOKなんですね。

これはValidatorのソースを読むとわかります。

ValidatorのvalidateUrlというメソッドの中では、

filter_var($value, FILTER_VALIDATE_URL)

というPHP標準関数を呼び出しています。

実はこの
FILTER_VALIDATE_URL
という指定ではrfc2396に準拠しているかは見ますが妥当なプロトコルを指定しているかまでは見ません。

したがって、
'url' => 'required|url'
というvalidation ruleの指定はwebサイトのURLチェックとしては不十分ということになるのです。

また、laravelにはactive-urlという似たような名前のvalidation ruleがありますが、こちらも注意が必要です。

これは最終的には実はそのホストのDNSのAレコードが存在するかというチェックだったりします。
興味のある人は是非ソースを読んでみてください。

ということで、今回のお話は、命名だけで信用せず、大事なところはソース読もうねー、というお話でした。

[0回]

• プログラミング
• COMMENT：0

Laravelは柔軟性のあるフレームワークだ。
しかし、それゆえに、迷いが生じることもある。

例えば、View Composer、機能はわかってもそれをいったいどこに書いたら良いの？とか、そんな迷いが生じる。

そんな迷いの中の一つがvalidationだ。

Laravel4系を使っているとvalidationの書き方や、書く場所なんかで迷ったりする。
Modelで書く、Controllerで書く、別のValidationクラスを作る、あるいはJeffreyの作成したForm Validationのバッケージを使う、どれもある意味正解でどれも絶対的な正解ではなかったりする。

そんな中で、ある一つの明確な解答を打ち出したのがLaravel5で登場するForm Request Validationだ。

これはRequestクラスを継承したものであるが、artisanコマンドで簡単にgenerateすることができる。

php artisan make:request CreateArticleRequest

こんな感じだ。

そうするとCreateArticleRequestクラスが自動生成され、そこにrulesというメソッドスタブが生成される。

そこで例えば下記のようなvalidationルールを書けばvalidationは終了だ。

public function rules()
{
　return [
　　‘title’ => ‘required|between:3,100’,
　　‘body’ => ‘required|min:10’,
　　'url' => 'required|url'
　];
}


しかも、これを実行するためには、controllerのactionでタイプヒンティングするだけでOK。

public function store(CreateArticleRequest $request)
{

}


という感じ。

Laravel4までは、constructor injectionしか利用できなかったが、
Laravel5では、method injectionが利用できるようになった。

これはその恩恵の一つだ。

これらの機能が使えるようになっただけでも、Laravel5に移行する十分な理由となると思う。

Laravel5へ移行する学習コストに比べて、移行することで将来的に節約できる実装コストの割合は大きい。

[0回]

• プログラミング
• COMMENT：0

Laravelで書かれたソースコードを読んでいると

@if (count($rows) !== 0)
　@foreach ($rows as $row)

[0回]

• プログラミング
• COMMENT：0

あまり芸術を理解する方ではない私も、
たまに有名な作家の美術展なんかは見に行くことがある。

自分の好みの絵などに出会うと、
綺麗だなーと見惚れてしまうこともある。

プロフィールにも書いているけど、

プログラミングは技術と芸術の中間

なんて思ってたりもする。


絵とか彫刻とか一般的な芸術品は、

「綺麗に描く(綺麗に作る)」

のと

「綺麗に見せる」

のはほぼイコールと言える。



でも、プログラミングは違う。


最近、ふと興味をもってbootstrapというCSSフレームワークの調査をした。

触れ込みとしては

「センスがない人でも非常に簡単にそれっぽい画面を作れる」

というもの。

確かに、bootstrapを使うと簡単に「綺麗に見せる」ことはできる。

でも、「綺麗に書く」ことができるか、というと必ずしもそうとは言えない。

例えば、

class=“text-right”

とCSSを書けば、右寄せで文字列を表示することができる。

しかしプログラマであれば、その場凌ぎで「右寄せ」という指定を都度するのではなく、例えば、「帳票の中の金額については右寄せ」という意味付けを行い、都度指定ではなく、より抽象化したレベルで指定したいと考えるだろう。

プログラミングは、「綺麗に書く」ことと「綺麗に見せる」ことが必ずしもイコールと言えないという点で、他の一般的な芸術とは異なる。

[0回]

• プログラミング
• COMMENT：0