がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

いわゆる「ページ読み込み時のイベント」の拾い方

JavaScript

なんとなし「onloadイベント」って感じで雑に把握をしているんだけど。
いわゆる「初期処理を書く場所」でございます。

いや、これを書かずにフラットなJS書いて「スマホでうまく動かなくておいちゃんにヘルプ求められて、ふと思い立ってonload的なイベントの中にJSかいたら動いた」とかいう嘘くさい事例が実体験であるので、やっぱりまぁ、それなりに気になるわけですよはい。

でまぁ。
JavaScriptやっていないおいちゃんでも「なんか色々あったよねぇ」くらいには記憶をしていて、ただ逆に「どれがよいのか」とか全然記憶していないので。
なんか書いたらきっと「詳しい人が突っ込んでくれるはず！！」っていう雑な発想で(笑)、一端、ざっくりと調べてみようかなぁ、と。

とりあえずざっくり調べてみた。

<body onload="onload_func();">
window.onload = function() {
    alert('onload');
};
window.addEventListener('load', function() {
    alert('onload');
});
window.addEventListener('DOMContentLoaded', function() {
    alert('onload');
});
document.addEventListener('DOMContentLoaded', function() {
    alert('onload');
});

この５種類が、どうも、あるぽい(addEventListenerの第三引数にfalseって書いてあるところもあったんだけど、なんかデフォルトがfalseっぽいので一端気にしない)。

んで。

<body onload="onload_func();">

は、明示的に「駄目」って書いてある所はなかったんだけど、なんとなく最近の風潮からして「好まれない」ような気がするんだよなぁ。
気のせい？？

window.onload = function() {
    alert('onload');
};

は明示的にNGっぽくて、端的には「複数のイベントハンドラが指定できない(後出し有効)」なので、色々とやばげ。

window.addEventListener('load', function() {
    alert('onload');
});

は割とあちこちで書いてあるし複数ハンドラも積めるんだけど(書いた順番に動くのは、保証されてるの？？？)。
どうも「loadイベント」自体が「画像とかcssとか、なんもかんも全部読み込み終わってから」なので、状況によっては「ちょいと重い」らしく、「気をつけて使えよ」くらいの事が書いてあった。


で、「HTMLの解析が終わった(画像とかCSSとかはしらん)」ってのが DOMContentLoaded ってイベントらしく、どうもコレが「現時点における正解」ぽい。
ただ

window.addEventListener('DOMContentLoaded', function() {
    alert('onload');
});
document.addEventListener('DOMContentLoaded', function() {
    alert('onload');
});

どっちも動いて、どっちがよいかは不明。

http://www.phenomena.co.jp/blog/2015/04/14/window-document-body-%E3%81%AEonloadonready%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AE%E3%81%9D%E3%82%8C%E3%81%9E%E3%82%8C%E3%81%AE%E9%81%95%E3%81%84%E3%81%AE%E8%A7%A3%E8%AA%AC/

最近のブラウザではdocument.onloadが完全に無くされました。

ってのを見つけたので、なんとなく、windowイベントにしておくのが無難なのかなぁ？？？


ってなわけで。
暫定トップは

window.addEventListener('DOMContentLoaded', function() {
    alert('onload');
});

この書き方、かなぁ。

批判の難しさ

親方

元ネタはこちら。
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できる」あたりとの関連性を想起するんだけど、実際、ど～なんだろ？？？

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