白黒の付け方

いや、無意識の内に、
白黒を付けたり、付けなかったりしているなぁと思ったもので、
書いておこうかなぁと思いまして。

あと、色々書いてますが、基本的には「白黒は付けた方が良い」と思っています。

１．白黒を付けるケース

「過去から現在までの数多くの事例により、有効性が却下されるケース」でしょうかね。
このケースなら、白黒が付けられる（というか、付けた方が良い）んじゃないかと。

例えば、本業になってしまいますが、
以下の様な条件の時に、

（１）新規の開発プロジェクト
（２）ビジネスとして成立させる
（３）すぐに、凍結する予定はなく、継続的にシステム改善する予定で、寿命の長いシステムを想定

「グローバル変数を使ってシステムを構築する」のは、「白か黒」か？
・・・「黒」じゃないですかね、と。
なんでかっていうと、

（１）これまでの散々な結果から考えて、新規のプロジェクトで導入する理由がない
（２）継続的にシステム改善をするにあたってのコストが高くなり、ビジネスとしても割に合わない

から。
いや、「何で、グローバル使うんですか？」と（一応）理由は聞いた方が良いとは思いますよ。
でも、↑の条件ですと、う～んと。
考えられるケースとしては、リリース「後」に、
「ホントに緊急の修正で、後でキレイにする前提で、一時的にグローバル変数を用いる」のは、
アリかなと思いますがね。
だから、「白黒付けたとしても、ずっと黒（白）とは限らない」というのはありますが、
でも、上記の様な時に、ずっと白黒を付けなければ、話は何時まで経っても進まないわけで。
「白黒付かないから、プロジェクトやらない」ってのは、違うなぁと思いますし。
「黒だから、プロジェクトやらない」は勿論アリですが。

今回の方が、少し具体的なだけで、
以下の記事と、同じ様な話になっちゃいましたね。

バランスの取り方 - gallu’s blog

２．白黒を付けないケース

（１）「事例が少なく、何とも言えない（ホントに少ないかは調べる必要はありますが）」
（２）「難解過ぎる為、白黒を付けるのが困難」
（３）「むしろ、白黒を付けない方が望ましい」

（１）は、新しいものだと、当然事例が少ないので、当てはまりやすいですね。
ホントに、新しいのかどうかってのはありますが。
だから、ここは、未知なものなので、
注意点を踏まえつつ、考えていけば良いんじゃないかと。

（２）は、芸術・科学・宗教辺りですかね。
まぁ、宗教は外しても良い？ですが、
科学の研究に関しては、僕は理科の成績がさっぱり（良くても５段階で３）でしたので、
さっぱり分からないんですが、
それでも、ビックリする様な内容を見て、「侮れないなぁ」と最近思う様になりましたので。
なので、それでも「白黒を付けるなとは"思いません"」が、
「安易」には、付けない方が良いんじゃないかと思いますね。

（３）は、また本業になってしまいますが、
例えば、「エディタによる生産性の差」とか。
VimとIDEで、「細かく計測」すれば、それは差は出るんでしょうけど、
例えば、その差が「8時間で終わるのと、9時間で終わる程度の差」で、
常に、8時間で終わる方を優先するの？っていう。
「8時間と、320時間」だったら分かるんですが。
それが、全然余裕が無くて切羽詰まっている様な状況なら、
あるいはとは思う（そういう状況を作らない様にする方が良いと思いますが）んですが、
たった１時間の差でねぇっていう。
なので、こういう白黒を付ける意味があまりない様なケースだと、
白黒を付ける方がかえって良くないんじゃないかと思いますね。
「白黒を付けるのは良いけど、それは意味ある？そんなに重要？逆にマイナスにならない？」って感じかと。
なんか、B'zのMONSTERって曲の「チンケな勝利」感がありますね。

あと、比較的最近あった個人的なケースで、上記全て当てはまりそうな話ですが、
以前に「仕事の進め方」について、仕事中に指摘を受けた事がありました。
「プログラムのコードが悪い」じゃないですよ、「仕事の進め方（それも、凄く細かい）」ですよ。
・・・新人の時には確かにありましたが、最近は無かったので。
で、そもそも進捗が悪かったので、そういう話になったのですが、その時僕は、
「その仕事の進め方で、必ず進捗が改善すると"言い切れますか"」と言いました。
いや、勿論改善されたかもしれないですが、
他にも問題があるなら、それだけでは改善は大してされないわけで。
自分が第三者だったら、「仕事の進め方も（細かくヒアリングして必要であれば）改善」しつつ、
「進捗が遅れている他の原因も調査して改善」しますかね。
なので、この場合は、「細かな仕事の進め方」という「事例が少なく且つ難解過ぎる」テーマなので、
白黒を付けない（か、上記の様に他の原因も探る）のが良いんじゃないかと思いますね。

あと、これは上記とは違い、
「複数人の間で、意見を出し合っている状況」の時ですが、
「意見A→反論B→反論C」みたいな時に、
「これ以上、反論が出ない時」がありますね。
リアルだと、「会議でシーンと静まり返った時」とか、
ネットだと、掲示板形式でよく見かけますが、「その意見がスルーされて、レスが進む」とか。
反論があるから反論が出るんなら、反論が無いなら、その意見は白なんじゃないですかね。
だから、リアルの会議だと「その○○さんの意見、反論無いしそれで良いんじゃないですか」と言ったりするんですが。
勿論、それが白じゃないなら、更に続ければ良いでしょうし。

少し、話が逸れましたが、
「白黒を付けるべきか否か」的なテーマについて、
少し整理が出来ましたので、書きました。

あと、すっかり恒例になってしまいましたが、
本日のBGMは・・・こちらかな。

DREAMS COME TRUE - 何度でも (from DWL 2015 Live Ver.) - YouTube

小室哲哉の引退に寄せて globe「 FACES PLACES」”顔”と"場所"を見つけたのか - さわやかトラウマ日記

小さな技術ネタ８つ

一つ一つが小さいので、まとめましたよ。

１．switchの分岐

もう、すっかりお約束かと思うんですが、

「switch($data)」と書いた時に、「==」で比較されますよっていうやつ。

で、以下の様な解決策が、提示されてますと。

ケースごとに異なる処理を、ポリモーフィズムで表現する（生PHPで） - Qiita

あるいは、上記の参考リンクに書かれている以下とか。

PHP :: switch の case 文で厳密な型比較をする [Tipsというかメモ]

・・・これなら別に、if～elseでもよくない？と思ってしまったんですよね（苦笑）

いや、別の記事にもリンク貼った事ありますが、

個人的に、以下の様なコードもあるので、stateパターンを使う事に否定的ってわけじゃないんですけど。

final_magic/view.php at master · kitoku-magic/final_magic · GitHub

ただ、分岐した「後」の、各クラス毎の処理の差異が殆どない様なケースだったら、

別に、そこまでしなくても良いんじゃないかなぁと。

「今はまだ少ないけど、これから差異が増える（この考えもYAGNI観点からは微妙ですが）」のが、

「確定」レベルならアリでしょうけど、そうじゃないのにって所じゃないですかね。

単に、「何がなんでもデザパタを適用する」的な、信者的な考えが苦手って話な気もしますけどね（苦笑）

２．HTMLのnameやDBのカラム名の、スネーク・キャメルの統一

結構、昔から時々感じていたんですけどね。

「user_id」と「userId」が混ざってますと。

で、混ざっているが故に、以下の様なコード（あくまで一例）をわざわざ書く必要があると。

$data = array(
  'user_id' => $_POST['userId'],
);

$entity->setUserId($_POST['user_id']);

$result = array(
  'userId' => $row['user_id'],
);

$entity->setUserId($row['user_id']);

とりあえず、最も多そうなケースとして、

「DBのカラムでuserIdというケースを見た事がない」のは、大文字・小文字を区別しない以下が原因かなと。

【MySQL】カラム名の大文字、小文字の区別 at softelメモ

といっても、別に「userId」というカラム名にしても良いじゃないかとも思うんですが、一旦置いておきましょう。

ただ、そうなると命名を統一するには「set_user_id()」となり、ここに違和感を感じる人が多いんだろうと。

いや、「setUserId」だろう？なんか、変じゃね？と。

といっても、set_user_idにしたら、何か問題が起きるのかという所なんでしょうと。

・・・何が理由があるんですかね？いや、命名が統一されているケースは、おそらく一度も見た事が無いので。
問題があるなら、統一されてなくても全然良いんですけど。

個人的にはスネーク派ですが、何も問題が無いなら「どちらかに統一」をって思うんですよね。

統一されていれば、キャネルでも良いよと。

３．DateTime::createFromFormat

これはマニアックな気がしますが、例えば以下の様(PHP7.2.10)に書くと。

<?php

// ケース１、問題無し
$datetime = new DateTime('24:59:59');
var_dump($datetime);

// ケース２、問題無し
$datetime = new DateTime();
$datetime->setTime(25, 0, 0);
var_dump($datetime);

// ケース３、問題無し
$datetime = DateTime::createFromFormat('H:i:s', '25:00:00');
var_dump($datetime);

// ケース４、指定されているフォーマットと違うので、$datetimeがfalseになる
$datetime = DateTime::createFromFormat('His', '25:00:00');
var_dump($datetime);

// ケース５、Fatal Error
$datetime = new DateTime('25:00:00');
var_dump($datetime);

$ php datetime_test.php

object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2018-11-25 00:59:59.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(10) "Asia/Tokyo"
}
object(DateTime)#2 (3) {
  ["date"]=>
  string(26) "2018-11-25 01:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(10) "Asia/Tokyo"
}
object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2018-11-25 01:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(10) "Asia/Tokyo"
}
bool(false)

Fatal error: Uncaught Exception: DateTime::__construct(): Failed to parse time string (25:00:00) at position 0 (2): Unexpected character in 
・・・以下、省略

となるので、「DateTime::createFromFormat()」が良いんじゃないの？と。

特にケース４が良いと思いますね。

応用すると、以下の様な事も出来ますし。

【PHP】DateTimeクラスでcheckdate()より汎用性のある日付チェックを行う - Qiita

注意点としては、上記の場合「年月日が翌日になる」って所でしょうか。

４．DateTime同士の日時比較

↑の３と関連しているんですが。

PHP: DateTime::diff - Manual

注意:

PHP 5.2.2 以降では、DateTime オブジェクトを 比較演算子 で比較できるようになりました。

ちょっと意外だったので、驚きましたね。

実例は、上記リンク先に書いてあるので、省略します。

５．stringとintの比較時のキャスト

例えば「リクエストパラメータの値（string）と、DBから取得してきた値（最近は、intのケースが多いか？）」を比較する時に、

「intをstringにキャスト」するか、「stringをintにキャストするか」的な話なんですが、

<?php

$request_parameter = '1a';
$db_value = 1;

if ((int) $request_parameter === $db_value)
{
  echo "string to int\n";
}

if ($request_parameter === (string) $db_value)
{
  echo "int to string\n";
}

$ php cast_test.php
string to int

と通ってしまうので、「intの方をstringにキャストする」が良いかなと。

といっても、値が大きくてfloatの場合、

stringにキャストしたら以下の様になるので、そこは別途注意でしょうけどね。

<?php

$db_value_int = PHP_INT_MAX;
$db_value_float = PHP_INT_MAX + 1;
var_dump($db_value_int);
var_dump($db_value_float);
var_dump((string) $db_value_int);
var_dump((string) $db_value_float);
var_dump(sprintf('%u', $db_value_int));
var_dump(sprintf('%u', $db_value_float));

$ php cast_test.php
int(9223372036854775807)
float(9.2233720368548E+18)
string(19) "9223372036854775807"
string(19) "9.2233720368548E+18"
string(19) "9223372036854775807"
string(19) "9223372036854775808"

６．NOT NULLが付いていない

「数値型の0や、文字列型の空文字の値に、特別な意味があったり、既存との値の体系的に、どうしてもNULLが必要」

ってケースぐらいですかね、NULLを許容する必要があるのって。

それすら微妙でしょうか？

user_idが0、日付が0001-01-01（ここは、さほど調べてませんが）、名前が空文字、statusが0・・・

statusが0のケースが時々って所じゃないですかね。

新規で作るならstatusが0の場合にも意味を持たせない方が良いと思いますけど。

書き切れないぐらい色々なケースがあるでしょうけど、やっぱりNOT NULLを付ける形が良いんじゃないかなと。

いや、単純に以下の様な事をいちいち意識したくないってのが、本音ですけどね（笑）

NULL撲滅委員会

７．O/Rマッピングについて

先日、以下の記事が盛り上がってましたので。

O/Rマッピングは百害あって一利なし！ - Qiita

これ、以下の記事では主題じゃなかったので書かなかったですが。

続・MVCのMのクラス設計草案など - 奇特なブログ

以下の様に、「SQLは書くけど、全部じゃないよ」的なO/Rマッパーじゃダメなんですかね。

other/order_repository_impl.php at master · kitoku-magic/other · GitHub

「和洋折衷」というか、良いとこ取りみたい感じですけど（笑）

あと、直でSQLを書いているというルール違反については、

「SELECT 」「INSERT INTO 」「UPDATE 」「DELETE FROM 」とかでGREPして、

以下のクラス「以外」がヒットしたら「おや？」とかね。

other/rdbms_storage_handler.php at master · kitoku-magic/other · GitHub

なので、既存のFWでも、あまりガッツリ使わなければ良いんじゃないかと思いますね。

要は、「変わったSQLを書くときに、どうか？」ってのがポイントなんじゃないのかと。

以下の様なSQLを、業務で書く必要があったらとか。

other/reservation_double_booking_check.php at master · kitoku-magic/other · GitHub

８．SQLで取ってきたデータに、使いたいカラムが含まれていない

上記の７とも少し絡むんですが、

「SQLで項目が指定可能だと良い」と。

いや、別にどうって事ない話なんですが。

というのも、項目が固定だと「不要だと思ったら、後で必要になった」的なケースが何度も起きて、

その度にソース修正するの？と。

だから、常に全項目取得（パフォーマンスはありますが、ここはさほど）で良いんでは？とも思いますが、

流石に不要項目（上記の通り、不要だと思ったら、後で必要になったりもしますがね）があまりにも多過ぎる場合にはとも思いまして。

なので、「項目を指定しなければ全項目取得だが、項目を指定する事も出来る」が良いかなと。

あと、別にコレSQLに限らず、外部のAPIを呼び出して、

必要なデータを取得する時に、項目が指定可能とかも。

外部APIの場合は、項目を細かく指定するのは難しいかもしれないので、

「全項目フラグ=true or false」みたくなるかもしれないですけどね。

以上です。

ここまで書き終えて、以下の話じゃないけど、

基本的に「大したことじゃない事」に、頭を使いたくないみたいですね（苦笑）

どこにリソースを突っ込むのか？ って選択は大事だよねぇ - gallu’s blog

あと、本日のBGM（曲の途中から）は・・・以下かな（笑）

Within Temptation - Whole World is Watching ft. Dave Pirner - YouTube

Radiohead - 2+2=5 - YouTube

2018年11月17日のダイジェスト

１．最初から全て決まっている様に見える

たま～に思う程度ではあるんですけどね。

そしたら、以下の記事を目にしまして。

『〈わたし〉は脳に操られているのか』著エリエザー・スタンバーグ レビュー①（※コメント返し中心） | 超個人的美学２～このブログは「超個人的美学と題するブログ」ではありません

『〈わたし〉は脳に操られているのか』レビュー②～人間は運命の奴隷であるのか？～ | 超個人的美学２～このブログは「超個人的美学と題するブログ」ではありません

『〈わたし〉は脳に操られているのか』レビュー③～思考とは脳内物質の化学反応であるのか？～ | 超個人的美学２～このブログは「超個人的美学と題するブログ」ではありません

あぁ・・・昔から「落ち着きがない」所がありましたけど、

それが「サーフィン」になり、

一方、妙に「ハマり症でオタクっぽい所」もありましたけど、

それが「本職」になったと。

だから、これはもう性格（と後天的な環境とか）的な部分で、変えようがないので、

グレードアップするしかないと思いましたね（笑）

「性格変える」って、昔以下の本読みましたけど、どうかなと思いますし。

性格は捨てられる
Amazon CAPTCHA

２． 川上量生｢中国のネット管理政策は正しい｣ | 最新の週刊東洋経済 | 東洋経済オンライン | 経済ニュースの新基準

この方、ブロッキングとか他を見てもそうですが、

個人の力を軽く見ている所があるんですかね。

といっても、以下の米津玄師は、ご自身の立ち上げたサービス出身の様ですので、

地上の星を、見誤ったんじゃないですかね。

｢米津玄師｣の曲がロングヒットし続ける理由 | スージー鈴木の「月間エンタメ大賞」 | 東洋経済オンライン | 経済ニュースの新基準

あぁ、確かに「キモい奇声」や「がなり声」や「ヤギ声」じゃなく、
聴きやすい声ではありますね。
あと、あぁ「温故知新」ですか。

コォ～～ルミ～～～～～ダァ～イナソ～～～！が、別の所で起きた様で（笑）

３． 憲法違反「ブロッキング議論」を誘発した、クールジャパン機構を巡る官民の癒着構造(山本一郎) - 個人 - Yahoo!ニュース

なんだか、関連が凄まじいですね。

FEには、さすがにビックリしましたけど。

加賀さんは、作り手「としては」優秀だったと思いましたけどね。

４． 港区南青山の児童相談所開設問題の総括と燻る反対論への是非（追記あり）(山本一郎) - 個人 - Yahoo!ニュース

ここで反論されている方は、他の上流の方だったり、

超上流の方と接してみると良いんじゃないかと思うんですけどね。

節約も大事ですが、考え方が「リッチ」じゃないなと。

５． 高知県立大学で蔵書3万8000冊焼却 貴重な郷土本､絶版本多数｜高知新聞

禁書的という声もありましたが、仮に「需要がない」なら、それは禁書ではないのではと。

これに限らず、「○○は禁止」って、ものによっては当然必要なわけですが、

昨今は、効果が出づらい様に思いますね。

６． ググっちゃダメなキーワード

リンクは貼りませんが、Laravel関連で・・・うお～～～～～～～！

「本番環境」には、さすがにビックリしましたね。

７． ソフバンCMの兄役ダンテさん、妻にバラエティ番組でフィギュアを処分され離婚 : ガハろぐNewsヽ(･ω･)/ｽﾞｺｰ

あえて擁護するなら、

「仕事をせず借金だらけで、趣味の物で部屋が一杯一杯になっていて歩けない」とかなら、

さすがに仕方ないかもと思いますけどね。

８． 【後払いガチャって何だ？】結果を見てから課金するか決められる『ぼくころ3』をやってみた [ファミ通App]

おお、これは企画の勝利感が。
よく考えましたね。

９． NHK「キズナアイ」騒動、バーチャルユーチューバーや萌え絵柄は番組のパーソナリティとして適切か(山本一郎) - 個人 - Yahoo!ニュース

これは思わないですが、

ただ、以下の胸を強調している様なのとかは、どうかなとは思うんですけどね。

実際、ライトノベルの表紙はキモい - Togetter

なんですが、こういう類のものは「スルー」してしまうものでして。

なんか、スルーすれば良いものを、スルーしないのを見ると、

「つながりすぎたのかなぁ」と思ってしまいますね。

１０． 可愛いも良いけどさぁ・・・

元DMMのFANZAが性に関する統計調査を発表 世界的に「熟女」への注目高まる - ライブドアニュース

そうそう（笑）

最近は、キャバクラに行くときも、「熟女キャバクラ」を選択する傾向にありますし（笑）

あと、熟女「ならでは」の「劣化の美学」というのもありますし（笑）

あと、以下とか（笑）

椎名林檎 - 至上の人生 - YouTube

ちょっと、やり過ぎだ林檎嬢！（笑）

ところで、上記のキズナアイを叩いた方は、むしろ「リアル人間」のこっちを叩いた方が。

１１． 【若者に朗報】東京オリンピックの奴隷ボランティアに５０代以上の人が殺到しボランティア数の目標達成:ハムスター速報

敗北感？いや・・・

むしろ、いつか来る「インデペンデンスデイ（ジャッジメントデイ？）」の到来を、

早める為に、ご協力していただけるとは、大変ありがたいじゃないですか！

１２． 世界とインターネットの「あちら側」と「こちら側」 - いつか電池がきれるまで

メジャーなのかマイナーなのかみたいな話で、

単に、ターゲットは違うけどやってる事は同じだと思うので、

特に、あちら側・こちら側って分断はしないですけどね。

１３． ハイキング中に生理になってしまった女性 → 友人男性の『イケメンすぎる対応』でピンチを脱出！ 男性の行動にネット上でも喝采集まる「こんなの絶対に惚れるわ！」 | ロケットニュース24

あぁ、そうか・・・これは「女性しか知らないはずの知識を、男性が知っている」のが、
「優しい」なのか「キモい」なのかだと。

「たくましい」と「暴力的」は「紙一重」だと思ってますが、
「優しい」と「キモい」も、そうかもしれないですね。

１４． 日本人が「他人のズル」を激しく妬む理由（プレジデントオンライン） - Yahoo!ニュース

う～ん、「違い」が例えば、

以下の「笛（ホイッスル？）の音が好き」みたくマニアック過ぎるとか（笑）

AURI - The Space Between (OFFICIAL LYRIC VIDEO) - YouTube

あ、僕の性癖もそうか（苦笑）

あるいは、「ピカソの絵って良いよね？（僕も良さが分からん）」みたく、「芸術的」なものとかは、

無理（少なくとも、相当キツイ）だと思ってますし、そういうものじゃないものを問題にした方が。

あと、好きなのは全然違うけど、嫌い（望まない）のは共通している場合も多いと思いますけどね。

１５． 契約を知らずに高稼働している人が多い件。 | トラッシュブリーフィング合同会社's Blog

おお、これは面白いですね。

このやり方だと後半でヤバいことにならね？と言う問題に気づいたときは、主要取引先だろうが気にせずどんどん指摘してあげよう。それで契約切られようが、こちらは義務を果たした訳だし、契約きったのは客側の判断だ。

いや、そうすると、切られた事はないですが、

スキルシートとしては、「期間が短くなりがち」で、大変に微妙になりましてね。

スキルシートの偽造の話を求職者からちょくちょく聞くが

上述の通り微妙なので、むしろしたいわ～～出来るなら。

この業界でよくある、採用の為のキラキラした求人にあこがれて勘違いして入ってくる人や、Web上で『SIerの技術者のレベル低くて高稼働、Webサービスはその逆！』的なこと言っちゃってる人がいて、そいつらの声が結構でかい感じの中、そんな人らの一部がrubyソースのリファクタリングもできなかったりテストコードも書けなかったりで、実は一部Webサービス運営の採用側から忌諱されてて、採用基準がSI出身者優遇になってたりとか、そんな話もあって。

過去の事を思い出してましたけど、人によるとしか。

偶然かもしれないですが、Web系に来てからは「NOT NULL」が「減った」という印象はありますけどね。

Webに流れる広告のカネは大きくなってきており、なにかを検索した際、ブログ然とした広告がずらっと並ぶ事も多くなってきました。個人的にも認知バイアス的な勘違いをさせられてしまう事が最近増えてる印象です。（禁煙のときにえらい目にあった。）TVだけの時代と同じようにですね。ちょっと今までとはワンランク上のリテラシーを持つ必要性を感じます。

そうですね。この辺があるので、検閲的な事はあまり効果がないと思ってしまう方ですね。

いや、良い事ばかりだとは思ってないですよ、選択肢が「多い」わけですからね。

１６． PMの必要条件に「技術力」は含まれるのか？ - gallu’s blog

「炎上しなくても書いてる」

ここが、ちょっとなぁ。

「PMは、コードを書かずに、それ以外の事を」と考える方ですけどね。

というのも、それ以外の事って、そんなに簡単な事ですかね。

いや、単に人材不足でそうなっているなら、仕方ないんですけどね。

１７． 解答：間違ったCSRF対策～初級編～ | 徳丸浩の日記

問題を見た時に、

・ログイン後に、セッションID変えてないな
・ENT_QUOTESとENT_COMPATが混ざっているから、シングルクオートをエスケープしていない系の脆弱性？
・もしかして、ワンタイムトークンの作り方が変？
・「type=submit」、怪しいよねぇ
・「$_POST['token'] !== $_SESSION['token']」、NULLとNULLの場合にすり抜けないか？

とは思ったんですけどね。

これを動かしてみましょう。あなたは現在被害者の立場です。mypage.phpを閲覧して対象スクリプトにログインします。
この状態で、あなた（被害者）は、CSRFの罠をうっかり閲覧してしまいました。

は？いや、むしろ「スクリプトをどうやって設置して踏ませるんだ？」という方を考えていた（だからtype=submitが怪しいと思った）んですが、特に必要ないと。
PoCの練習をした方が良いかもしれませんね。

１８． 解答：間違ったCSRF対策～中級編～ | 徳丸浩の日記

こっちは、以下かなと思いましたが、どうやら違う様で。

PHPで==の代わりにstrcmp関数を使うことによる問題点 - hnwの日記

strcmpは、↑が原因か覚えてませんが、いつからか使わなくなってましたけどね。

１９． 聴けば世界が広がる、歴代アルバム売上トップ32 - 脱R論

「おわりに」の所に着目したんですが。

音楽は誰でも気軽に楽しめるコンテンツではあるんだけど、
それ故に物語性をメインに据えるにはやや不向きなジャンルなのかな。
だから音楽は何かのサブコンテンツとして消費される位置付けになった。

むしろ、サブなので、「マルチタスクが容易」という強みが（笑）

現状の僕のライフスタイルには、この方があってますね。

物語が嫌いとは「間違っても」言えないですが（笑）時間がかかりますのでねぇ。

それに聴覚からの刺激は他の刺激に比べて
最も脳にダイレクトに作用するらしい。
だから気軽に様々な効果が期待できるのが音楽というわけだ。

この仕事してから特にそうですが、「耳」を使わないなぁと。

でも、せっかくあるので、有効活用しようかと（笑）

２０．音楽

前回から、そんな傾向がありましたが、

しばらくは、色々なアーティストの曲を聴いてみようかと。

（１）エアロスミス

ナイン・ライヴス
https://www.amazon.co.jp/dp/B005OCSU2Y

こちらは、以前にベストは聴いていたわけですが、

特に「Hole In My Soul」がヤバい！

Aerosmith - Hole In My Soul - YouTube

何という、綺麗なメロディ（Bメロ以降）のバラード・・・

他も、「Full Circle」等々、思ったよりバラエティに富んでいて、よろしかったですね。

洋楽慣れしていて、タイラーの声に抵抗が無ければ良いんじゃないかと。

では、次行ってみよう（笑）

（２）ZOOLANDER

‎ZOOLANDERの「I JUST WANNA BE LOVED - Single」をApple Musicで

たまたま見かけて、ちょっと聴いてみたわけですが、良いぞ！

これは「テクノ」ですか。

テクノは、もっと長くても良いと思うので、強いて言えばその辺がって所ですね。

では、次行ってみよう（笑）

（３）宇多田ヒカル

B'zが勝てなかった（シングルもアルバムも）このお方に触れないわけには（笑）

初恋
https://www.amazon.co.jp/dp/B07CKQR6T3

似たタイプ（女性シンガーソングライターつながり）のKOKIAとの比較だと、

「バラードはKOKIAの方が良いが、売れ線はヒッキーの方が良い」という感じですね。

ただ、タイトル曲の「初恋」は、バックのストリングス込みで良い味を出していて良い！

あと、「嫉妬されるべき人生」ですかね。

本人のインタビューからは、幸せ的な曲に感じますが、曲調的にそうは思えませんでしたけど（笑）

宇多田ヒカル 『初恋』 〈諸行無常〉という言葉があるけど、それを理解して受け入れるのはそんなに簡単なことじゃない | Mikiki

これは、もうヒッキーは嫉妬され続けるだろうと自分で思って書いたんですかね。

キャリアとか見ると、ヒッキー（や息子）に生まれたいとは思わなかったんですけど。

しかし、この人はやっぱり独特過ぎるので、今後の展開も楽しみですね。

では、次行ってみよう（笑）

（４）Mr.Children

また、B'zが勝てなかった（シングルとオリジナルアルバム）このお方を。

深海
https://www.amazon.co.jp/dp/B00005H020

いや、これがフロイドの狂気に似ているとかで、じゃあと思いまして。

雰囲気と、曲が繋がっている点が似てるぐらいでしたけどね。

ただ、こっちは当たり前ですが、「死ぬほど聴きやすい」ので、楽でしたけどね。

ところで、「名もなき詩」は、歌詞「も」良かったみたいで。

http://j-lyric.net/artist/a001c7a/l006fd9.html

誰かを想いやりゃあだになり
自分の胸につきささる

だけど
あるがままの心で生きようと願うから
人はまた傷ついてゆく

傷付くのは、あるがままに生きている故じゃないですかね。

愛情ってゆう形のないもの
伝えるのはいつも困難だね

この曲（に限りませんが）もそうですが、全くですね。

どうやら、ミスチルは、以下を読むと、

他にも、こういうタイプの曲があるみたいですね。

Mr.Childrenの優しくない歌 - NAVER まとめ

なので、もう少し・・・・次行ってみよう（笑）

（５）Radiohead

実は全然知らなかったんですが、フロイドを聴いていた時に時々名前を見かけたのと、

以下の記事を読んで、じゃあと（笑）

椎名林檎はなぜ「加爾基 精液 栗ノ花」を作ったか(椎名林檎とレディオヘッド論) - 本とのこと

で、以下を聴いてみたわけですが。

KID A
Amazon CAPTCHA

カルキ～とジャンルも違うし別に似てないけど、「商業的自殺」つながりではあるのかなと（笑）

・・・これは、フロイドを越えて「聴きにくいランキングトップ」ですね（苦笑）

ですが、これまでの経験値がものをいったか、比較的早く馴染みましたが。

特にだと、「Everything In Its Right Place」と「The National Anthem」が良かったですね。

あと、詞を書いているトム・ヨークは「絶望請負人」ですね（苦笑）

「俺が、あらゆる絶望を表現してやる！」とでも言わんばかりの。

でも、それがどうやら聴き手側には「良い効果（とは限らないですが、勿論）」を与える傾向もあるようで、

だから、人気なのか（苦笑）

ところで、以下の記事がありましたが。

【歌詞解説】Everything in Its Right Place / Radiohead - 我々は正しいものを許せるのか？ - 深読み、Radiohead通信｜歌詞和訳と曲の解釈

「2 + 2 = 5」じゃなくて、「4」じゃないんですかね。

あと、「2 + 2 = 4」は「正しい」ですが、「正義」ではないと思いますね。

「2 + 2 = 4です！正義です！」って、「声高」に言う事ではないと思いますし。

むしろ、「合っている（間違っていない）」って状態を軽んじているのかなと。以下とか見ると。

最近の小学生は足し算を『さくらんぼ計算』という解法で解くことを強制され、テストで省略すると減点されているという話 - Togetter

白黒を付けるのが難しい話も確かにありますが、

だからこそ、まずは「正しい（合っている）」って状態を、適切に評価するのが大事だと思いますね。

そうじゃないと、「2 + 2 = 3？4？5？」、

どれが正しいのが分からない！と迷走しがちになる習慣が付いてしまうのではと。

う～ん、これはアルバム全部聴いてみたいレベルでしたが、まだまだ他にもありますので、

次行ってみよう・・・もう無いけど（笑）

続・MVCのMのクラス設計草案など

前回記事：
MVCのMのクラス設計草案など - 奇特なブログ

前回の草案ソースとの差分（ちょっと多過ぎますが）：
モデルクラスの設計草案を作成（一旦完成） · kitoku-magic/other@f89baf7 · GitHub

もう、そんなに書く事も浮かばないんですけどね。

とりあえず、「何でもかんでも自作でやろうとしないで、利用出来るものは利用した方が良い」と思いますね。

既存のフレームワークやらライブラリやらを使って、車輪の再発明するなと。

というのも、業務で書くにあたって↑のコードを書くのは、

業務ロジックはゼロですし、完全に無駄な時間なわけで。

勿論、既存のフレームワークやライブラリで対応出来なかったり、

業務要件的に必要だったり、その他の事情でフレームワークを導入出来ないとかなら、

書く必要はあるわけですけどね。

っていう事と、現存のPHPフレームワークで、デフォルトでDDDの構造になっているものが・・・ありますかね？

って所を考えると、現存のフレームワークのクラス構造じゃダメなのか？という。

実際、DDDの案件の時は、Cakeでしたけどフレームワークの機能は殆ど使わず（モデル以外は使える）自作でしたからね。

なので、その部分はロスなわけですが、そのロスを取り返せるのかどうか（勿論、取り返せるなら良い）と。

・・・以下の、「覆水盆に返らず」みたいですね。勿論、グダグダ設計のグローバルは、言うまでもないとして。

覆水は盆に返せるのか？ 余談 - gallu’s blog

あと、これは↑とは別の現場ですが、そこでのDDDでは、

「Modelというクラス名なのに、フィールドに対するgetterとsetter（こっちは無かったかも）しか無かった」

という、なんじゃこりゃ？感（これはエンティティでは？）なケースもあり、

「用語が指している意味がバラバラ」かもとは思いましたね。

ただ、その現場は、資料で詳しく解説があったので、

「あぁ、そういう意味で使ってるのね」とは思ったので、特に問題無いかとは思いましたけど。

これは、DDDの原理原則からは外れているのかもしれないですが、

原理原則の形で「しか」使えないなら、柔軟性には欠けるかなぁと。

だから、前回のリンクにもありましたが、以下のやり方もアリだと思いますし。

PHP Mentors -> ドメイン駆動設計のリポジトリパターンをプロジェクトへ持ち込む時の話

別件だと、MVCで「コントローラークラスは１つ or 複数？」論争とか、

以下の様な、「どっちに書く？」系とか、最近は気にしなくなったかなと。

Model、どうすっかねぇ？ 的な - gallu’s blog

あとは、DDDの時に思ったのが、「１クラスの担当責務」にうるさいので、

Utilクラスが無かったり、Constantが超細分化（これ自体は良いと思うが、ちゃんと構成を考える必要がある）したりと。

それに拘ったからですかね、色々なクラスに「private const NEW_LINE = "\r\n"」みたいなコードがあったのは。

いや、PHP_EOLじゃダメなんですか？って感じなんですけど。

Utilとか、色々なクラスで使うのに、何故Utilに書かない？ってのは、

「縦割り」というか、横を意識しなかったのかなと。

更に・・・まぁ、良いわ。せめて今回僕が↑に書いたコードぐらいには、

共通化はして欲しい（fetch()とか、やろうと思えば、まだ出来るけど）とは思いましたね。

まとめる（というか、前回のに追加する）と、プロジェクト的（要件・メンバー構成・期間・予算）に、

どの方法が最適解か、よ～く検討するって所でしょうか。

DDDは、本を見ても「対象範囲がかなり広い」ので、

気を付けて導入しないとハイリスク・ローリターンになると思いますのでね。

あと、本日のBGMは、B'zの「弱い男」 http://j-lyric.net/artist/a00067d/l043c9d.html でした。

いや、こういう微妙な話は、自分一人では決めれない弱い男なので（笑）

traitに期待し過ぎ？（笑）

ピンと来て、出来てからにしようかと思ったんですが、まぁ良いかなと（笑）

「ログの出力をしたいけど、クラス毎にログの出力先を変えたい」という仕様があったとして、

↓のコード（PHP5.2というか、traitが無い状況の場合）を書いたんですが。

<?php

class log
{
  private $log_save_path;

  public function __construct($called_class_instance)
  {
    $this->set_log_save_path(get_class($called_class_instance));
  }

  public function set_log_save_path($called_class_name)
  {
    $this->log_save_path = '/tmp/' . $called_class_name;
  }

  public function write($log_message)
  {
    file_put_contents($this->log_save_path, $log_message . PHP_EOL, FILE_APPEND);
  }
}

<?php

require_once('log.php');
require_once('test_service.php');

class test_controller
{
  private $log;

  public function __construct()
  {
    $this->log = new log($this);
  }

  public function exec()
  {
    $this->log->write('controller1');

    $service = new test_service();
    $service->exec();

    $this->log->write('controller2');
  }
}

$test_controller = new test_controller();
$test_controller->exec();

<?php

require_once('log.php');

class test_service
{
  private $log;

  public function __construct()
  {
    $this->log = new log($this);
  }

  public function exec()
  {
    $this->log->write('service1');
  }
}

とする事で、test_controllerとtest_serviceで、保存先が別になると。
で、これをPHP7.2（trait有りバージョン）で書くと、

<?php

trait log
{
  // privateでも動くのは、ちょっとビックリ
  private function write($log_message)
  {
    // get_called_class()は、PHP5.3以上で使用可能なので、traitが使えれば絶対使える
    file_put_contents('/tmp/' . get_called_class(), $log_message . PHP_EOL, FILE_APPEND);
  }
}

<?php

require_once('log.php');
require_once('test_service.php');

class test_controller
{
  use log;

  public function exec()
  {
    $this->write('controller1');

    $service = new test_service();
    $service->exec();

    $this->write('controller2');
  }
}

$test_controller = new test_controller();
$test_controller->exec();

<?php

require_once('log.php');

class test_service
{
  use log;

  public function exec()
  {
    $this->write('service1');
  }
}

ということで、簡素化したかなとは思うものの、

それほどでも？とも思い、タイトルの事を思ったんですけどね（笑）

なんですが、以下を見てみた所。

PHPのトレイトを使うならおさえておきたい５つのこと

あぁ、「既に継承しているクラスで、継承元の親クラスに追加しない（それ以外のクラスでも使う処理なら、場所が不適切）で、更に機能を増やしたい時」に良さそうですね。

当初、ログやDBハンドルとか、色々な所で使うクラスをtraitにすれば良いのでは？と思っていたんですが、

さすがに今回は、処理が単純過ぎたから、本領発揮とはいかなかった様ですね（笑）

良い事例が見つかったら、改めてということで。

あと、本日のBGMは、中島みゆきの二艘の船 http://j-lyric.net/artist/a000701/l00f4b9.html でした（笑）