いろいろ技術的メモ

仕事に差し障りない範囲で、関連ネタなど…

jquery.validationEngine 1

なかなか便利だよね。これ。

 

公式はこれかな。

github.com

 

 

1:load順

各言語のlanguageファイルが先なの?

直感的じゃないけど、公式のdemoのソース見る限り、そんな感じだ。

 

 

2:カスタマイズ

-ja.jsファイルを書き換えろって記述いっぱいあるんだけど、書き換えても「そんな定義はない」って怒られるな。

jqv:custom rule not found

最小構成でhtmlファイルで記述すると、この方法で動くんだけど…。環境で何かまずいのかもしれん。面倒なので調べない。

 ここでは別アプローチについて記述する。demoみていると、普通にあるので、そっちみてもOK。

 

validationEngineのフォームへの適用などを記述した、scriptタグの、その下あたりで以下の関数などを定義。このregexp判定自体には突っ込みどころがあるのだが、それは後述。

function checkKatakana(field, rules, i, options){
	if ( !field.val().match( /^[ア-ンァ-ォャ-ョー]+$/ ) ) {
		// un match
		return "* 全角カタカナで入力してください";
	} else {
		return "OK!";
	}
}

 関数の引数の説明は以下の感じ。demoの中で書いてある。

/**
* @param {jqObject} the field where the validation applies
* @param {Array[String]} validation rules for this field
* @param {int} rule index
* @param {Map} form options
* @return an error string if validation failed
*/

 

要はチェックしてエラーがあればエラーメッセージを返せば良い。返さなければ成功となる。上の関数ではelse節を消せば本来の正しい判定となる。

ローカルチェック用でsubmitさせたくなければ、else節を書いて何かreturnしてやると、問題なくてもエラー扱いで送信されない。関数の判定のチェック用に。

なお、判定の呼び出し記述は以下。 

class="validate[required,maxSize[128],funcCall[checkKatakana]]"

すごく楽ー。javaScriptでクライアント側で入力チェックって、汎用的に出来そうなのに妙に面倒だったもんなぁ。web系しばらくサボってたから、こんなの知らなかったよ。w 

この funcCallで入力判定を仕込むアプローチは、全体では使わないけど特定画面で変な判定が必要なケースとか、既存実装があって、ちょっとファイル改変の影響が怖いとかの時には、悪くない方法かも。regexpチェックするだけなら、改変の方が早そうではあるけどね。w

 

 

3:ところで。

上のカタカナ判定のRegexp判定部分は、webで拾ってきたもの。これ意味分からないんだよね。w

他に見かけるのは

/^[ァ-ンー]+$/

こんな感じの、もっとシンプルなものが多いかな。実はまだこっちの方が筋が通ってる。あんなに分ける必要がある文字コードってあるのかな。shift-jisとeuc-jpとutf-8は確認したけど。おそらく指定範囲が被っているので微妙では?内部で最適化してくれるのかな。

 

そして、これらの判定だと、以下のカタカナ文章はエラーとなる。

ヴァルヴレイヴ

この辺、文字コードにも依るのだが、UTF-8の場合、以下のコードを持つ。

UTF8 3byte(e3)

カタカナは [e3 82 a1] ァ から始まるが、[e3 83 b3] ン で終わっていない。

わざわざ長音記号を含めているのは、これがン以降で少し離れているからだが、間の他の文字を使わない確証がないのなら、入れておく方が良いのかもしれない。w

これを考慮する場合、以下の判定になる。(UTF-8の場合)

/^[ァ-ヺー]+$/

 

まぁ、ちょっとしたネタですが。w

 

DBアクセス関連

このあたりまで踏み込んでみると、

PHP+Laravel5.x

という環境の凶悪な楽さ加減がわかるわ…w

 

1:準備

zxnw.hateblo.jp

 DBアクセスに成功していること。

コード的には、(以下、PHP5.6.x + 5.0.x環境

  • $ php artisan make:model tasks
    Model created successfully.
    Created Migration: 2017_07_14_080808_create_tasks_table
  • \database\migrations 以下のmigrate用phpファイルでテーブル構造を修正。
    $table->string('name');
    を追加程度で。
  • php artisan migrate
  • Seeder書いて使うなら、このへん。適当に自前insertしても。
  • コントローラ冒頭でuse宣言
    use App\tasks;
  • getIndex()などで
    $tasks = tasks::all(['id', 'name' ]);

 これで全件取得。

 

 

2:ごりごり使う

PHPにはヒアドキュメントあったよね。

もうあれでごりっとSQL書いちゃって、要素部分だけ?にすればいいんじゃね?

$q = <<< EOM
select * from tasks where id= ? order by id;
EOM;
$tasks = DB::select( $q, [ $id ] );

 はい。パラメータクエリ出来た。うわあ。糞楽だのう、これ。w

複数要素のパラメータ放り込みたい時も、第二引数は配列なんで、ここに並べるだけ。お手軽だわー。

 

★ベタ過ぎる件?

クエリビルダとかあるらしいけど、複雑になってビルダに突っ込んだ要素がむやみに増えると、それが本当に意図通りのsqlなのか、あんまり信用出来ねーんだよなー。まぁこんな簡単な単純selectなsqlなら問題や曖昧さなんて起きないだろうけどさー。

あとSQL自体の、個別単体テスト。ヒアドキュメントで書くと、これだけでコピペでテキストエディタ上で要素埋めてDB直に放り込んで、結果確認出来る。でもビルダーに細切れで入れてると、これ、問題起きたときに、どの書き方が悪いのか突き止めるの面倒くさくね?

DB側仕様が未確定の状態で走り出して、もう書いちゃった細切れを、後から仕様変更に合わせて修正も、面倒くさくね?これ、あり得ないって思うかもしれんけど、実作業だと往々にして「仕様確定の方が実装開始より無駄に遅い」なんてザラなんだぜ?w

SQLベタなら、これも対応しやすいし、テストも想定可能だしなー。どうなんだろうね?そのへん。PHPUnitとか使うつもりで書けば、まだマシになる?ならないよなぁ。その前の話だもんなぁ。

 

 

3:その他

DB::insert
DB::update
DB::delete

 このへん。ノリはselectと同じ。

この辺は普通にプログラマやってれば見えるだろうけど、ものすごく定型的な全力で自動化出来るような、決まり切ったSQLを書くことになる。こういうのはビルダ的ツール使うのもありな部分だと思う。

SQLは結局、どうしてもselectは人間が頑張って書く方が、目的に沿ったコード書ける気がするなー。単なるパフォーマンス部分は、DB側のoptimizerが頑張るにしても、ソフトウェア的・仕様的に求められる論理的整合性は判断してくれないからなぁ。

 

 

ついに。

 

なぜ、徒然記事を書きたくなるのだろうなー。

これを作るとだめなんですよ。技術ネタなんてそんなに頻繁に出るもんじゃないけど、世界や人への苦言には限りがないからのう。w

技術ネタ記事って、その技術にそれなりに時間かけるとか、ある程度詰めて仕事で使うから、結果が出るまでやりこんだ上で、それをさらに消化してまとめる必要があるので。あと今更 PL/SQLネタとか書いても、枯れてるし、ぐぐれば済んじゃうからなー。俺がぐぐって困らない限り、俺が書く意味自体ないでしょ?

 

 

www.kouritsu30.com

 

これねー。 

その通りなんだよねー。(終了

 

あの、話す価値のない人間を早めに見限るのは、正しいことだと思いますよ。

人間が現状、必ず死ぬ以上、そしてそれがいつか不明な以上、自分に残された時間を正しく測定する手段は存在しないわけです。それが数分後なのか、明日なのか、数十年後なのかは不明。

故に、人間にとって一番無駄にしてはならないのは、有限であるにも関わらず総量を測定できない、自分の時間。これを、可能な限り価値ある事象に対してつかうべき。これは揺らぎようがない真実だと考えられるのですよ。

例えば、俺はわりとゲーマーなんで、ゲームに結構時間を浪費()するのですけども。ぶっちゃければ、バカと会話するより、俺個人にとって有意義で楽しいから、ゲームやるわけです。どれだけ論理と普遍的に観測される現実を表現してやっても、相手が理解に到達しないなら、それは無駄であり、虚しいわけです。そんなくだらないことにエネルギーと時間を消費するなら、その間はゲームでもやってた方がマシ、なんですなぁ。w

さらに言えば、話す価値のある人間との対話は、なかなかに楽しい時間を過ごせるわけでね。それは相互に価値を生む、有意義なものとなるでしょう。切磋琢磨。そういうものにもつながる。バカと無駄に時間をかけて、実にもならない対話をするくらいなら、これを求めるべき、なんですなぁ。

となると。そもそも自分の周囲にバカを増やす事こそが愚行なのですよ。話が通じない人間を切り捨てるのは、むしろ、さっさと次に行って話が通じる人間を探す行為につながるのですな。その方がよほど有意義なのですよ。これが。

 

故に、結論として、バカはさっさと見限るに限る。

これですよ。これ。w

 

 

参照DBの変更とか

www.it-tech-box.com

 

パスワードも忘れるよねー。

 

・基本設定

  • DB関連の設定は、\config\database.php にある。デフォではmySQL。それ以降の設定は基本的には、そのまま弄らないこと。
  • ID,パスワード,ポート設定やdatabase名などは、プロジェクトのrootディレクトリ直下にある、 .env ファイル。.env.exampleファイルを見ながら編集する。
  • homestead環境でcomposerから引っ張ってきたデータであれば、そのまま何もしなくても稼働するかも。だが、これが罠である気が。知らないままコア機能触れちゃうからなー。DBにログイン出来なくてseederやmigrateが失敗する場合は、この辺の設定が問題だ。

 

・モデル

php artisan make:model Task

単純だけど、裏の隠れ処理が多すぎて、知らないと困惑するのだよなぁ。

  1. この場合、app直下にmodelファイルが生成される。
  2. DB側のテーブル名は Tasksにする。キーのうち、自分の主キーはidに。
  3. model内に何も書かなくても、基底クラスの基本機能により、TaskというモデルがTasksというテーブルにリンクし、主キーidで、一通りの一覧データ取得など基本機能を実行可能になる。
  4. 利用するController (\app\Http\Controllers以下) 内などで、use App\Task; 宣言することで参照される。
  5. view()で画面側に設定してやれば、あとはviewのお仕事。(\resources\views以下)

 

Controllerの表示処理内部で、

$tasks = Task::all(['id', 'taskname', 'taskinfo' ]);
return view ('tasks.index')->with('tasks', $tasks );

 

などと書いてやれば、全件取得し、view側に変数を名称指定で放り込める。あとはblade.php側で ループ処理絡めて表示させればよい。マスタデータなんかは、このノリで問題ないな。

この場合、balde側ではForm::selectなんかは使えないかも。それでなくても、タグべた書きでloopさせる方が、むしろ記述としてもわかりやすい気がするなー。

 

→使えたw

{!! Form::select('tsk', ['0' => '選んでね!'] + array_pluck($tasks, 'taskname', 'id'), $tsele, ['class' => 'form-control', 'id' => 'tsks' ] ) !!}

 

ふーむ。悪くない。なるほど、便利だね!

 

 

Laravel関連まとめ 1

とりあえず、初期段階の作業をまとめる。ver1。

以下記事のざっくりまとめ。

 

zxnw.hateblo.jp

zxnw.hateblo.jp

zxnw.hateblo.jp

 

 

・virtual boxと vagrantと、git for windows

ここまでは、何か変なことをするにしても、ほぼ固定。windows環境下のソフトなので問題はないと思われる。

 

・基礎環境構築

vagrant box add laravel/homestead
後、

PHP7.x系環境でlaravel 5.4.xなど、最新環境でつつくなら、最新branch取ってくる。
git clone https://github.com/laravel/homestead.git Homestead
PHP5.6.x系で環境構築。5.0.x系など、古いバージョンのlaravelを利用するなら。
git clone -b 2.0 https://github.com/laravel/homestead.git Homestead

init.shをたたき、homestead.yamlを編集して、vagrant upする流れは、ほぼ同様か。

gitの古いbranchを動かすと、homestead.yamlがなぜだかユーザルートの.homesteadディレクトリ以下に入るので、下の複数稼働は難しいか?

 

 

 ・複数homestead

homestead構築後、複数種類のhomesteadを管理するなら、rbファイルの編集が必須となる。laravel自体が ver依存性むちゃくちゃ強いし、複数環境で立ち回る方が便利かも。

\Homestead\scripts\homestead.rb 内部の、"homestead-7"を、4カ所書き換えれば別名に変更可能。変更後に以下実行。

vagrant up

 これで変更後名称で仮想環境が生成される。

 

・作業用備忘。

cd ~/Homestead
vagrant ssh

vagrant up --provision

vagrant halt

 

・homestead.yamlの sites指定を編集後について:

sites:
- map: test.app
to: /home/vagrant/Code/test4/public

 map指定部分は、その定義で直接アクセスする。時間が空くと忘れるわー。192.168.10.10で上の方でipアドレス登録されてるから、ついつい http://192.168.10.10/test.app/ とかでアクセスして「動かないなー?」とか思っちゃうわー。

正しくは

http://test.app

 これがアクセス先URL。

で、このままだと当然ipアドレスは解決出来ないので、Windows\System32\drivers\etc\hosts に 192.168.10.10をベタうち登録する。

192.168.10.10 test.app

これで基本的なテスト環境は構築出来る。ver分岐も対応出来る。

複数sitesは、hostsに全部同じipアドレスで登録しても問題なし。とんだ先のserver側でコンテンツ分岐する問題。

このsites設定、nginxの設定あたりに直接放り込まれるのかなー。web鯖のsites設定にそのままリンクするのかな。調べてないけど。

 

 

Seeder

これ割と重要な機能。テストデータや初期データも作れるし。

laravel.com

5.4のSeedingの基本的な使い方。

 

 

基本:

  1. php artisan make:seeder TasksTableSeeder
  2. database\seeds\DatabaseSeeder.phpに、生成されたseederを追加してやる。生成されるseederも同じ場所にある。
  3. 作成したTasksTableSeederに、生成挙動を追加する。一括生成するなら、database\factories\ModelFactory.php にルールを書き込む。
  4. artisan経由で実行。データ生成させる。この場合の実行方法は複数パターンある。

 

1:

seederを、ファイル名指定で作成出来る。名称の命名規則的には、テーブル名にTableSeederを付与すれば良いだろう。

database\seeds\ 以下に作成される。

DatabaseSeeder.phpには、自動で追加されたりはしない。

また、この処理では、テンプレートが作成されるだけで、app内のモデルなどは、ちゃんとuse指定の追加等が必要。

use App\Task;
use Illuminate\Database\Eloquent\Model;

など。

 

 

 

3:

生成挙動の実装にも複数パターンが考えられる。

$faker = \Faker\Factory::create();
for ( $i=0; $i<50; $i++ ) {
	$task = new Task();
	$task->name = $faker->name;
	$task->save();
}

fakerを作成し、ループ内で Modelクラスをnewで生成して、直接saveをたたき、データを構築する。項目数が多いと面倒だが、ある程度のパターンから外れるケースにも対応出来そう。

factory(Task::class, 50)->create();

 database\factories\ModelFactory.phpに、あらかじめ自動処理のひな形設定が必要。

それが済んでいるなら、記述的にはとてもシンプル。単純にデータ件数を増やしたい場合も扱いやすいかも。 

DB::table('tasks')->insert([
	'name' => str_random(12),
]);

 DBファサード経由でtable指定で、直接insert処理を実行する。

結果的に、やっていることは変わらないが、この方法をとる場合、DBとの結合が強くなる点は問題か。疎結合を目指すなら、この方法は良くないだろう。

 

 

4:

seedsの実行パターンは複数ある。

php artisan db:seed --class="TasksTableSeeder"

最初の実行方法は、作成したseeder単体で指定してキックする。今作ったテーブルだけ生成するなら、これでいい。このパターンなら、DatabaseSeeder.phpに追記しなくても実行可能。

php artisan db:seed

二つ目は、DatabaseSeeder.phpに登録済みのseederを一括実行するパターン。実行のたびに、登録済みの全seederがごりごり稼働するので、複数登録処理の場合は、データ量をどんどん増やせる。ある程度のデータ件数がほしいなら、この流れがいいかも。

php artisan migrate:refresh --seed

三つ目は、migrationをちゃんと作成している場合に使える。テーブル内のデータを一回全削除してリセットし、seed作成を連続して実行する。seeder全体の整合性など、データ状態の再設定にもよい。

 

これらパターンを考慮するとき、migrationも、seederも、フレームワークとartisanで作成しておく方が、利便性や安定性は増すと思われる。

 

 

 

 

で、Laravelってどうやって使うのよ?

laravel.com

 

Laravelの Quickstartページ。

5.1にも、近似の内容のQuickstartがあるっていうか、確認してないけど同じ?

5.3以降はURL変えただけだと見つからなかったけど、あるのかも。

 

laravel.com

こっちは5.4。Modelなど

 

 

英語だけど、コマンド入れていく流れなので、まぁ見ながら触るのは一般的技術屋なら問題なかろう。ここでは、このQuickstartから見えるLaravelの方針や概念をつらつら書いてみる。

 

  1. artisanつかえ
  2. 叩いて出来たtemplateを埋めろ
  3. DBのテーブルもコマンドで出来るから、構築時と同じノリでコマンド叩けば本番だって構築出来るで!
  4. version変わって、Laravelの内部構成とか実装の方向とか、むちゃくちゃ変わっても、artisan使っていれば、出来るtemplateの場所が問題なだけだし、それは最新のファイルでも検索すればええで

 

要するに、こういうことなのかなー。

この辺触りながら、Laravel4のソースの移植だの、5.1らしいソースの移植取り込みだのをやってみよう。

 

 工程自体は以下の流れ。

  1. DBのテーブル定義あたりを php artisan make:migration する
  2. php artisan migrateで、テーブル生成させる
  3. php artisan make:model で、テーブルデータの構造クラスを起こす。ただしほぼ自動なので、レコードをそのまま取るなら、生成だけでおk
  4. URLのREST的なルーティングを作成。Laravel5.4あたりでは、routes/web.php で、ファイル名すら違うことに注意。ただ、Routes Fasadeは利用出来るので、コピペでよさそう。
  5. view作りながら web.phpの処理をメンテナンスしていく。サンプルだとControllerいじったりしてるんだけど、そこまでは踏み込まないのか。
  6. web.phpで参照しているRequestは、5.4環境では use Illuminate\Http\Request; が正しい。Illuminate\Support\Facades\Requestだとこける。

 

新しく Laravel環境を立てて、何かしら編集などすると、かならず以下の工程がセット。

 

  1. Homestead.yamlの sites:を編集する(追加など
  2. VMvagrant haltする
  3. windowsのhostsにも追記
  4. VMvagrant up --provision する
  5. sites:や hostsに追加したホストにアクセス

 

 

 

//use Illuminate\Support\Facades\Request;
//5.4からこっち??
use Illuminate\Http\Request;

5.1と5.4で、こういうライブラリ周りの違いが多すぎて、公式のサンプルが全く追従できてないっていうあたりが、なんだか微妙だなぁ。ちゃんと5.4のドキュメントを見ないとだめかも。あと実作業時にバージョン違いなんかが発生すると、まぁまずまともに動かないって事だな。

最近のフレームワークとかって、短期間に変化しすぎて初心者お断りになるの、なんだかなぁ感あるなー。