批判の難しさ

元ネタはこちら。
https://twicolle-plus.com/articles/424400

100人のうち批判する人が2人いたとしても、たかがその2人のために過度な謙遜をする必要は無いとマツコデラックスは言っていますが、まさにその通りですよね！批判されやすい世の中ですが、気にし過ぎはストレスの元となってしまいます。

一方で「よく分かる」話でもあるんだけど、もう一方で「別の考え方が出てくる事もある」かなぁ、と。

記憶頼りなので、細部はうろ覚えなのですが。
こんな感じの台詞を、伺った事があります。

「ちょっとくらい手を抜いても品質が落ちても、10人のうち、9人までは気づかないのよ。
　でも、1人はその"手を抜いた"、"品質が落ちた"を見抜く。見抜いて、そのままいなくなる。
　そうすると、また残った10人のうち9人までは気づかないんだけど……で、どんどん、上客がいなくなる。」

プロフェッショナルとしてこのあたりの諸々を考えると、非常に怖いんですよねぇ。
せめてそこで「苦情の一つも、批判の一つも、言って欲しい」ってなる……んだけど、それもなかなかに難しい。多分きっと「言われる前に気づけよ」って、言われちゃうだろうし。

勿論、いわゆる「モンスターな汚客様」の話をいちいち真に受けても疲れるだけ、なんだけど。
一方で、やっぱり「言ってくださる批判」は、一度は耳をかたむけておいたほうが「何かのヒントになる」事も多いんじゃないかなぁ、とかも、思うんですよね。

その辺のさじ加減は、言うにしても聞くにしても、本当に難しくはあるんだけど。
この辺の難しさと厳しさと、だからこその「気づいた時に、それとなく伝える」事の大切さは、定期的にしみじみと考える所でございます。

豆腐干絲の覚え書き

豆腐干絲の覚え書き。

買った所によるのかもしれないけど(たしか、富岡商店さんで買ったやつ、のはず)。
500g入ってるヤツで
・「(二人)2食で食い切る」のはかなりぱつぱつ。4等分して(二人)4食にしたほうがいいと思う
・「解凍して」「小分けにして」「冷凍」でよさそう
・使う前。下ゆでは1分～2分で十分。5分だと麺がブツブツに切れる。「沸騰した中に突っ込んで」1分くらい

塩焼きそばにして食ったですが、美味でございました。
味付けは、250gの豆腐干絲に諸々具材で
・オイスターソース大さじ1
・醤油大さじ1
・塩 小さじ1/2
で「塩気が足りない」くらい。
麺を1/4にしたら、ちょうどよいのかもしれない。

思ったより美味だったので、時々試してみませう。

ぶり大根

ぶり大根

概ね、土井先生の https://www.lettuceclub.net/recipe/dish/12595/ のレシピなのですが。
ちぃと甘かったのとかあったので、少しだけおいちゃん好みに修正したレシピを、覚え書き的に。

材料
・大根：1/2本
・ぶり：適度
・調味料

調理工程

1．
・大根は2～3cmほどの半月切り。皮付きでOK
・ぶりは一口大に

2．
鍋に大根とぶりを投入、ショウガを大さじ1くらい投入。
水を「ぎりぎりヒタヒタ」くらいまで入れる

3．
強火で沸かす。
灰汁を取る。
大体、数分の前半くらい

4.
ラカンカ大さじ3、酒大さじ4を入れて中火(煮え玉が出る程度)で10分

5.
醤油大さじ3を加えて、目安は30分～。煮汁がある程度減るまで(1/2～1/3)煮る

6.
醤油大さじ2(ちょい)を加えて5分くらい煮る

7.
一回ある程度冷まして、味をしゅませる。

• • • • • • • • • • • • • • • • • -

元レシピの「砂糖大さじ4＋みりん大さじ4」相当だと、結構甘いんだよねぇ。ブリのほうは良かったんだけど、大根が結構甘い。
なので、もう少し甘さ控えめにするとよいかなぁ、と。

大根は、少し古いのでも柔らかくなったので、無問題。
ブリもパサパサにならなかったので、美味。

「黄金律」って必ずしもいいとは限らないよねぇ

今回の発端は、こちら。

https://twitter.com/saya1001kirinn/status/1093441567493316614

アジャイル開発にて納期が過ぎてて遅れている状況で、 詳細設計はなく、画面設計には書かれていないけど、ここはお客さん的に必要になるだろうとか、ここに入力制限かけておかないとシステムロジックが破綻するのでは？というところが出てきたらその都度上に確認して実装しますか？？

A) 現段階の仕様のまま実装。お客さんに指摘されたらする
B) 現段階の仕様で実装。お客さんに見せる時に伝えはする
C) 上に確認をとり実装(納品に更に遅れは生じる)
D) 確認とらず実装(どちらにせよ後に必要になるから)

A～Dは、語るのに必要そうなんでおいちゃんが勝手に採番しました。

さて。
簡単な前提条件としては
・詳細設計はなく、画面設計には書かれていないけど、ここはお客さん的に必要になる
・ここに入力制限かけておかないとシステムロジックが破綻する
ってな課題に対して「ど～する？」っていう疑問でございます。

まずAは、基本的に「悪手」です。
なにが悪手って、顧客側から見たら「こいつらプロフェッショナルな面して金取ってるくせに、俺らが指摘しないとこんな事にも気づかない/気づけないのか？」という疑念を抱かれる事が多いために、悪手です。
勿論「気づかれなくてそのまま納品」って可能性も博打的にあるのですが、それで実際に「必要になったり」「問題が起きたり」したら、事前に分かってるよりももうちょっと「緊急でタイトで厄介」になる可能性が高いので、原則として悪手です。

Bは、基本的に「悪手」ですが、選択せざるを得ないシーンもあります。
色々とアレがナニな話も絡むので詳細は伏せますが、まぁ「やむを得ず」というシーンは、割と、色々。
ただこの場合「詳細設計はなく、画面設計には書かれていない」責任分岐点とかコストとか費用とかの話を置いてきぼりにしすぎると後で痛い事になりがちなので、その辺はしっかりと押さえておいたり〆ておいたりしたほうが無難です。

Cは、本来的には「この選択肢の中ではベストな選択」と言えます。
ただ「遅延」に対するお客様の反応(と、今までに積み上げてきたポイントに起因する会員ランク( https://gallu.hatenadiary.jp/entry/2018/10/11/234610 ))によっては、なかなか切り出し難いケースというのも無くはない、のが現状ではございます。
その場合、Bに限りなく近いC、とか、まぁグラデーションが出てくるのかなぁ、と。

で、本題(やっとかい)。
Dは、定期的に見かけるのですが、実はこれ、結構な「悪手」である可能性が高いものでございます。

かみ砕いて。
まず端的に、発端が
・詳細設計はなく、画面設計には書かれていないけど、ここはお客さん的に必要になる
・ここに入力制限かけておかないとシステムロジックが破綻する
なのですが。これ「本当にそうなの？」っていうあたりから、まず検討が必要です。

もちろん「設計時に抜け落ちている」可能性もあるのですが、一方で「別にいらない/なにか別にガード手段がある」等、「実は必要ではなかった」なんてケースも少なからずあるんですね。
おいちゃんの観測の範囲内だと
・「ちゃんとお客さまに確認する人」の提言は、実際に提言を受け入れたほうがよいもののほうが多い
・「ちゃんとお客さまに確認しない人」の提言は、提言が蛇足だったりお客様のニーズと逆方向だったりする事が多い
ように思われるのですが、どんなもんでしょ？？
それは、本当に「必要」なんでしょうか？ 「あったほうがよい」ではなくて「ないと困る/システムが破綻する」？

で、もう一つ。
「じゃぁ必要」であるといったん仮定をして(そうしなきゃ話が進まん)。
「そのコストはどこから捻出されるんでしょ？」というお話。
事前の設計やらそれの合意やらは、ほぼ確実に「その案件の金額」に関連してくるので。
その辺の調整抜きに「これは必要だと思うから余計に手を動かしておこう」は、割と本気で「余計というより蛇足」になる可能性が、色々と否定できないんですね。
比較的無難なところで「その着手は無駄だった」から、比較的面倒なところで「前回も無料で修正してくれたんだから今回も無料で修正してくれるべきだ」っていう厄介な顧客教育の方向性まで、まぁ色々。

この辺で、個人的には「黄金律」とかいうあたりを想起する事が多くて。
黄金律自体は、以前に https://gallu.hatenadiary.jp/entry/20120404/p1 でも言及していたことがあるのですが。
「自分が良いだろうと思うもの」をそのまま相手に提供して、それが「本当に相手にとってよいものである」かどうか、ってのは、個人的には割と「びみょ～～」だと思ってるんですよねぇ。
割と定期的に「余計なお節介」だったり、下手をすると「相手にとってはbadな提案」である可能性だって、無いわけではない、わけで。
「自分が良くないと思うもの(銀の教訓)」はまぁ「相手にとっても良くない」可能性も高いので、「ここに入力制限かけておかないとシステムロジックが破綻する」あたりはまぁまだ「提言をしておいたほうがよい」ような気もするのですが、とはいえその辺も「工数と納期とご予算次第」ってところもありますしねぇ。
この辺、自分の善意だけで「きっとこれが必要なはず！！」をあんまり推し進めると、それが「必ずしも良い結果を招き続ける」とは限らないんですよねぇ。
「地獄への道は善意で舗装されている」なんて言葉もありますし。

或いは。
「カウボーイコーディング」とイメージ的にかぶる事も多いんですよねぇおいちゃん的に。
一端、カウボーイコーディングについては

https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA#%E3%82%AB%E3%82%A6%E3%83%9C%E3%83%BC%E3%82%A4%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%AF%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%A8%E3%81%AF%E7%95%B0%E3%81%AA%E3%82%8B

カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うことである。好ましくない状態を指すのに使う言葉であり

https://tmytokai.github.io/open-ed/activity/scrum/text01/page03.html

チーム内の開発者達が各イテレーション内でコミニュケーションを取らずバラバラ好き勝手に開発をおこなう状況を考えてみましょう。
このような開発手法を「カウボーイコーディング」と言います。

https://www.nttpc.co.jp/yougo/%E3%82%AB%E3%82%A6%E3%83%9C%E3%83%BC%E3%82%A4%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0.html

情報システムやソフトウェアを開発するとき、それぞれの開発者が自分が最も良いと思う手法で作業を行って、統制が取れていないこと。

あたりを参照してくださいませ。

システム開発……に限らんと思うのですが。
複数人が関連している以上、「必要なコミュニケーション」は、必要ってぐらいなんだから当然に「必要」なものでございます。
別にコール・ド・バレエのように「(ほぼ)寸分の狂いもないほどに均一」であれ、とは思わないのですが。
とはいえ、何のためにコーディング規約が存在するのか？ とか、もう少し考えてもいいんじゃないかなぁ、と思う瞬間は、少なからずあるものでございます、し、それ以前に「この言語を使っているんだから」とか「このフレームワークを使っているんだから」とかいう暗黙の了解も、限度や程度はあれど、多少は存在していると思うのです*1。
そういった時に。
いや別に「積極的に四六時中、のべつ幕無しに語り続けろ」とは思わないのですが、必要なコミュニケーションすらまともに取らずに「絶対領域( https://gallu.hatenadiary.jp/entry/2018/12/01/112949 )の中にこもりっぱなし」というのも、果たして如何なものなのかなぁ？ と。

で、そういった系譜の延長線に「確認とらず実装」っていう選択肢があるような気がする……というか実際に幾度か実例を見ているので*2。
その辺を考えると。

選択肢のDは「一見、親切に見える」のですが、実際には「地獄へ続く善意＋コミュニケーション忌避」に起因する「結構、山盛りの地雷」がある可能性が高いんですよねぇ。
…………なんていうことを考えながら、くだんのツイートを拝見しておりました。

その辺、他の人はどうなんでしょうかねぇ？
とかいう疑問などを投げかけつつ、書いてみました。

追伸
「そもそも"アジャイルで納期"ってなんだよ？」ってのは、一旦、丈夫な棚の上に上げておいてくださいませ。

*1:例えば「PHPの文法的にあり得ない書き方」とかされると、割と本気で殺意を覚えたりするものでございます……

*2:で、そこそこトラブっているのもやっぱり見ているので

ソレはきっと、ビューティフル・ドリーマー

直近、インスパイアされたのはこの記事なのですが。
https://www.fnn.jp/posts/00417790HDK

――なぜログインパスワードは暗号化されていなかった？

宅ふぁいる便は20年ぐらい前から動いているサービスで最初から暗号化はされていませんでしたが、いつか暗号化しなければならないという予定はありました。
ただサービスが大きいことと資源の問題などもあったため、計画を立ているところで今回の漏えいが起きてしまいました。

うんうん「ありがちだなぁ」と。

「収益に直接的にプラスに直結する実装」以外について、割とよく見かけるのですが………特にセキュリティホール関連。次点として「おウンコ汚い書き方のコード」とか「マジックナンバー埋め込みまくり」とか。
諸々に曰く「後でやります」。

後で、って、いつ？

おいちゃんがまだ若かりしころにあった「うる星やつら2 ビューティフル・ドリーマー」という映画がありまして。
まぁ端的には「繰り返される今日、永遠に来ない明日」という感じが、物語の主軸の一つになるのですが。

「明日やります」って、大体こないんですよねぇなんかしみじみ思い出すんですよこの映画を*1。

んで、まぁ重い腰を上げて「んじゃ、着手しますか」となっても、多分手始めに「まず全体の調査*2」が必要で。
それにもそこそこコストがかかるんで、一定確率で「ここで零れ落ちる」んですよねぇ気力とか財力とか諸々が。

んでまぁ結局「じゃぁいったん今はなしで。後日、対応しましょう」で以降永遠にループ。
「明日」っていいよねぇ永遠に来ないんだから(笑

いやまぁ真面目なお話をしますと。
実際問題「今、直近に最優先で」やるべきかどうか？ ってのに疑問符が付きつけられるのはまぁ、色々とわからんでもないのですが。
ただそうやって「いつまでも後回し」にすると「そのうち痛い目にあうよ？」という現実は、宅ふぁいる便さんが「これでもか！ これでもか！ えいっ！ えいっ！」ってほど思いっきり、実現化してくださいましたので。

恐らく「後回しにしたタスク」は、重要度をインクリメントしていって、ある程度までは後回しにしても「ある程度以上」は後回しに出来ない、くらいのなんかギミックがあったほうがいいんじゃなかろうか、って思うんですよねぇ。

なんてことを、色々な諸々を思い出しながら。

*1:映画は多分「傑作」の部類だと思われるので、ご覧になったことがない方は、一度くらい見ておいてもよいんじゃないか、と思われます

*2:映画だと、ハリアー戦闘機と戦車の大砲で「全体把握」を試みてましたねぇ

静的変数について調べてみた

マニュアルに「静的変数(static variables)」って書かれてるやつ、ですね。
端的には、関数(含むメソッド)の中で

function hoge() {
    static $i = 0;
}

とか、ってやつです。

で、これ、メソッドでも書けるのですが。
その時の「staticで保持している単位」が今一つ不明だったんで、ちぃと興味があって。
マニュアルに書いていない(と思う。記載があったら、箇所を教えていただけると幸い)内容なんで。
一端、PHP PHP 7.3.1(と、別環境で手持ちにあった7.2.13) で動かしてみた結果でございます。

コードは、こんなん。

class Hoge
{
    public function h()
    {
        static $class = null;
        static $i = 0;
        $class = $class ?? get_called_class();
        $i ++;
        echo "{$class}:{$i}\n";
    }
}

class Foo extends Hoge
{
}

class Bar extends Hoge
{
}


$h_obj = new Hoge();
$h_obj2 = new Hoge();
$f_obj = new Foo();
$b_obj = new Bar();

$h_obj->h();
$h_obj2->h();
$f_obj->h();
$b_obj->h();

$h_obj3 = clone $h_obj2;
$h_obj2->h();
$h_obj3->h();

結果は、こんなん。

Hoge:1
Hoge:2
Foo:1
Bar:1
Hoge:3
Hoge:4

何となくだけど、staticの変数の中身、class単位で持ってそうな感じだなぁ。
だから、Hogeについては「別インスタンス」だろうが「cloneでのcopy」だろうが、同じ値を地続きで持ってる。
な～～んとなく、privateなメソッドを「同じclassの、別インスタンスからcallできる」あたりとの関連性を想起するんだけど、実際、ど～なんだろ？？？

ちょいと興味があったのと、思ったより興味深い結果になったので、メモり。

魔力干渉系魔法と魔法干渉系魔法

一般に「魔法干渉系」と呼ばれる魔法が、いくつか存在する。
例えば「魔法吸収」であったり「魔法発動阻害」であったり、或いは「魔法分解」や「解呪」といった類いのものや、このあたりの行き着くところが絶対魔法防御(アンチ・マジック・シェル)である。
しかし、これらは厳密には「魔法が効果を成す前の、魔力の流れに干渉をする」呪文であり、正しくは「魔力干渉系」と呼称されるべき呪文群、になる。
故に「魔法が効果を発した後の結果」に対する干渉は、原則として出来ない。

端的には「治療呪文を解呪」しても、治療効果がなくなりはしない。
これは、治療呪文自体は「(ほぼ)瞬時に効果を発揮する」ため、に、解呪対象となる「魔力」はすでに「結果を成した後なので霧散しているから」である。

一方で、いわゆる「呪いなどの解呪」や「永続呪文の解呪」については、正確には2種類の作用のどちらか(ないしその複合)となる。

一つは、多くの「呪いや永続呪文」は、ある程度ループするように「魔力を周囲から吸い取って効果を成す」回路が組み込まれており、その回路の動作自体にも(当然だが)魔力が使われる。
そのため「対象の呪に対する一切の魔力供給を、一瞬でも完全に破壊する」事で「回路の維持が不可能」となり呪文が壊れる。その「魔力供給の遮断」を行うのが、一般的な「解呪」の一つの手法である。
これに対抗するために、特に「呪い」の場合は「魔力を蓄える」「偽装する」など、様々な方法で「魔力供給の瞬断」に対抗するような術式が組まれている、事が多い。

もう一つが、端的には「熱を発し続ける」術式に対して「冷却し続ける」術式を重ねて「効果を対消滅させる」事で、実質的に「解呪」と同じ効果を生み出す、という方法がある。
この場合は「対象術式の解析」の精度が重要なファクターになるため、どちらかというと「魔力制御と魔力分析に長けた」タイプの術者が、この方法を得意とする。
対抗手段は「術式の解析を阻害する」等があり、これも一部の術式では、そういったものが組み込まれている。

魔法吸収系などについては簡単で。効果が成ったにしても「成りきれない魔力」というのは大概、魔法事象の周辺に漂っているもの、なので。
吸収系は、基本的にそれらの「成りきれなかった魔力」を吸収しているだけ、である。

魔法発動障害は、単純に「集約している魔力を散らしている」事が多い。
亜種として「集約している魔力に(使う術式にとって)使いにくい色(ベクトル)を付けて」魔法発動を阻害している、ようなケースもある。

これらの究極である「アンチ・マジック・シェル」は、周辺の魔力に干渉をして「魔力が効果を成す前に全ての魔力をジャミングする」術式である。
よく「効果範囲外からのマジックミサイルなども打ち消せる」などの事象から「魔力干渉系」とは見なされないようだが、あの術式は、実際には「範囲：ほぼ無限」であり、術者を標的にしてきている魔法について「魔力干渉をしている」だけに過ぎない。
アンチ・マジック・シェルの「範囲：ほぼ無限」については、その性質から「因果律作用系」が一部混ざっていると思われるが、そのあたりの考察はまた後日。

しかし、あまり知られていないが、真に「魔法干渉系」と呼ばれる術式が、存在しないわけではない。
一般的な魔術師程度では噂すら聞いたことがないであろうが、超が付くほど一流の術者であれば、噂くらいは聞いたことがあるかもしれない。

「真の」魔法干渉系は、「すでに成った」魔法に干渉をする事が出来る。
理屈は単純で、端的には「魔法そのものに時間干渉し、その魔法が成る前の魔力に戻した上で魔力干渉をする」というのが、その根本原理である。
故に、「すでに成った魔法」についても、普通に干渉をしてくる。

この術式が怖いのが、「一般的には知られていない」為に「この術式に対する防壁が組み込まれた術式」はあまり存在せず、そのため「大半の術式が、抵抗の余地もなく解呪される」事にある。
かつ、もし干渉時間を長くすると「治療呪文をキャンセルする」といった、今までの常識を根底から覆すような術式すらも、組む事ができる。

「超」が2つ以上程度つく術者どうしの術式の場合は、最低限これらに「ある程度」抵抗するような呪文回路が組み込まれている事が多く、それがない術式は基本的に「無防備すぎて、一切の効果を及ぼさない」と考えてよい。
ちなみに、いくつかの上位種が持つ「低レベルの呪文に対する完全防御」は、この「真・魔法干渉系」の亜種である、と考えられている(「低レベル呪文」だけ、なのは、「時間に干渉できる」魔力量に(かなり低いところで)上限があるため、である)。

「真の魔法干渉系」術式の会得は、普通に「才能がある」程度では、星のごとき高さの難易度ではあるが。
それでも「知っている」か「知らないか」は、それなりに重要な「違い」になると思い、ここに記す。