/ 最近 .rdf 追記 設定 本棚

脳log[2019-11-06~]



2019年11月06日 (水) [B! コミュニケーション] なぜ「事実」と「意見」を区別して話せない人がいるのか。 | Books&Apps」■タイトルから抱く期待と本文を読んだ感想が一致しない。そういう意味でブコメの流れはもっともである。■新聞の投書欄でたしか読んだけど、医者にかかって「風邪みたいなんです」「それを判断するのは私です(ムスッ」みたいなやりとりって感じ悪いじゃない(少なくとも投稿者はそう受け取っていた)。言い方があるだろうと(「どうしてそう考えたのか話してもらえますか?」)。最初に対立関係や上下関係を作って得する人間が存在するのかと(医者も患者も上司も部下も得していない。ただし医者と上司の目的がマウンティングである場合はこの限りにない)。で、誰が改める?■人間は道具ではないし、頭が付いてるし、それを活用できない上司が無能に見える。もちろんまだ信用して任せるには足りない新人かもしれなくて、判断のプロセスをいちいち確かめる必要があったのかもしれないけど、その場合でも上司に人を育てる視点がまるでないことが、やはり無能に見せる。勝手に育つ、骨のない奴はやめちまえ、なんてのは人余り世代の甘えでしょ。判断の機会を奪い、そのプロセスを鍛えることもせず、部下はいつまでも上司のためのテープレコーダーなのか?(テープ? IC と言い直しても同じだな。ボイスレコーダーが正解か)


2019年11月05日 (火) ミネルヴァの続刊をずっと待っていたのだけど、そのせいで他のシリーズに手を出せないでいたのだけど(そういう気質、あるよね)、作家には続刊か新シリーズかのオプションが与えられており、選んだ結果の新シリーズだったらしい。20190703のスライドの作者のツイッターからあいだに一人を挟んで再び名前を見かけることがなければそれまでだった。それは惜しい(どっちが?)。


2019年11月04日 (月) ひこにゃん(?)のアイコンでツイッターをやっている人をブックマークしていて、なんとなし歴史・地理・漢字クラスタに分類していたのだけど、ふいに AGC(AtCoder Grand Contest)に参加した話が出てきたりもして、たった一人の人間であっても底は知れない。


2019年10月31日 (木) 疑問に対する答え。「関心の分離や単一責任の原則に通じるところがあるんでしょうか?」■もっとミクロな話で、曖昧さを残さない、惑わせない、その余地を残さないってことだと理解している。■今回の件で言えば、ヌル終端されないケースがあるのかないのかということ。実際は固定長配列で間に合うのだから用意された配列にヌル文字が含まれないケースは存在しないと考えられる。だから仕様でヌル文字の存在を仮定する。存在しない場合を許さないし仮定しない。それが Assertive であるということ。■曖昧な態度をとれば論理がつながらないし、すべてのあり得るケースを十全にカバーしようとしたときに負担が増える。想定ケースに対して念のために1だけ余分に対応できるようにしたコードに対応するためにさらに1の余分が必要になり、それに対応するコードはさらに……。■カバーする必要性に気がつかずに、論理のギャップに対して2人の人間が異なる見方をすれば、それがバグの始まり。■追加された比較演算子のテストはヌル文字が存在しないケースにアイデンティティを与えて存在を認め、仕様として規定した。だとすれば今後(そして既存のコードも) MYDEVMODE の sz と名の付くメンバにヌル文字の存在を仮定することができなくなり、たとえばメッセージボックスをはじめとする文字列関数にそのまま渡すことがバグの温床になる。律儀にやるなら _MAX_PATH+1+1 のバッファに一時コピーしなければいけない。正気か?■現実をテストケースにすれば実装をいじる必要はなかった。実在しないケースをテストにして実装をそれに合わせたのがあの PR。正気か?■俺は怠け者だから行動する者には負けるけど(「うんこコード、放置しててすまんです」)、その動きが右へ進み左へ進みその間に後退もしている(前進はしていない)、というものではないかという疑いの目は向けている。■■■「一応、strncpy的な関数の使い方を誤るとNUL終端されない文字列を作れますので、絶対要らない対応、というわけでもないと思ってました。」 テストに対する勘違いがあると思う。ヌル終端しないコードに対してこのテストと実装の修正で何ができるのか、シナリオで示して欲しい。もちろんそれを伝えはしない。聞く耳ねーからな。無駄無駄無駄。■念のために書くけど、「ヌル文字の存在を仮定する」というのを「ヌル文字の存在を信じて暴走すべき(それを許容すべき)である」などと曲解されていては全く浮かばれない。ヌル文字の後ろを比較対象にするのがあるべき仕様の外であるなら(wmemcmp を使わない理由)、構造体のために確保されたメモリの外を比較対象にするのもあるべき仕様からは外れている(wcsncmp を使う理由)。どちらも否定していないし、今は無関係。混同している人間が誤っている。


2019年10月30日 (水) ぶん殴りたい。共通の理解の上で意見が合わないのなら、それは価値観の違いであり、それをどうこうすることはできない。だけどある程度共通のものがないとどうしたって戦争が避けられないから、批判に堪える出版物を引用する。自分個人の考えや感覚でそれができるとは考えない。しかし価値観以前に共通の理解をこの者との間に築くことができないせいで、無駄に消耗する。全くの無益。耳を塞いで他人にでたらめな要求を押し付けるふるまいを「犯罪的」だというのだ。自己の無謬性にそこまで確信を持てるとは大した自信家じゃないか。「本物は違う」とはこのことではないか。俺の方はといえば事実関係に白黒が付かないことに気も狂わんばかりになっているというのに。■https://github.com/sakura-editor/sakura/pull/1081#pullrequestreview-307582232 の指摘は最初から十分に理解できるものだった(なのに不備を詫びることができるのは報告者の人徳だ)。ここにアクセス違反のおそれがあるとヒントを与えられても見つけられない者に、最初から何が期待できるのかという考えもある。万事この程度の理解度で弁明する者のいない既存コードをふんわりざっくりけなすようなまねをするから、「お前が」「(わざわざ)言うな」の念が募る。■俺はこの者の人格に絶望している。


2019年10月29日 (火) 日曜日にあった ABC。ちょっと毛色が違った D 問題。「D - Water Bottle」■難しポイント。sin と tan 間違えた。弧度法から度数法への変換を間違えた。高校数学では tan/sin/cos しか習わないので Ruby の Math モジュールのドキュメントを漁って atan と atan2 と atanh のどれが自分の求めるものか確かめないといけなかった(しかも最初 sin 系の関数を試していて角度の変換も間違えた)。これが難しいとか高校生に鼻で笑われる。


2019年10月26日 (土) もうはばかる理由もないので最初(sourceforge.net)から思っていたことを書くけど、「定石だから」ってのは理由になりはしない。そもそもその「定石」がローカルルールや迷信の類ではないのかという疑いがあるが、そこをクリアしたとしてもやはり同じ。デザインパターンがそうだ。広く流布し認められたパターンであっても、パターンカタログに載っていること自体が、パターンを採用する理由になるわけではない。これまで読んだどのパターン本でも、パターンが適用できる具体的なシナリオと、パターンが持つメリットとデメリットの両方と、同時に比較考量すべき別のパターンが併記されていた。「定石だから」で留まるのは浅はかなんだ(「手段を目的化してしまうと見失いがち。手段は常に目的に対してテストされ、いつでも置き換えられなければいけない」)。盲信するならせめて対象として権威を選ぶくらいはしないと馬鹿なんだ。


2019年10月25日 (金) Android 9 Pie にインストールした VLC for Android 3.1.4。ファイルからの相対パスで音楽ファイルを列挙した m3u プレイリスト(文字コードは UTF-8)。パスに [] を含んでるファイルを再生してくれないので、それぞれ %5B%5D に置換する必要があった(※手を加えたのはファイルシステム上のパスではなく、プレイリスト内のパス)。なんで? 二重にパーセントエンコードされても不思議じゃないんだけど、なんで OK なの? これじゃ %5B という3文字を含むパスと [ という1文字を含むパスを区別できないじゃない。


2019年10月21日 (月) 旅行予約サイトの「今あなた以外に○○人が見ています」はウソだったことが判明 - GIGAZINE」■まじめに実装すると人とサーバーにコストがかかるし、下手すると逆効果(「今あなた以外にゼロ人が見ています」)の可能性があるので、完璧にコスト(手段)とパフォーマンス(効果)を最適化した結果だと思う。手段を目的化してしまうと見失いがち。手段は常に目的に対してテストされ、いつでも置き換えられなければいけない。


2019年10月17日 (木) 提出 #8002336 - AtCoder Beginner Contest 088」に対して1バイト縮めた「提出 #8002578 - AtCoder Beginner Contest 088」。でも Ruby で *最速* である hanada3355 という人の「提出 #5777010 - AtCoder Beginner Contest 088」を手直しするだけで 151 バイトのスクリプトになるんだよなあ(※p の引数解釈とか条件演算子と文字リテラルの解釈揺れをバージョン2.3.3に最適化すると多少縮むかも)。196 バイト、195 バイトのレベルではない。手法としては「ちょっとだけGOLFに走った」と同じなんだけど、見てしまってから真似はできない。発想の転換が欲しい。■とか書いている間に 187 バイトの「提出 #8002816 - AtCoder Beginner Contest 088」と 186 バイトの「提出 #8002824 - AtCoder Beginner Contest 088」。目の付け所がずれている。でも自分としては添削を受けているようでテクニックの引き出しが増えて良い。■■■矢継ぎ早にくり出される新アイディアが楽しい。特に出力変数 c に例外値 -1 の役割まで持たせてループのストッパーにするこれが白眉。「提出 #8007594 - AtCoder Beginner Contest 088」。■これもえげつない。「提出 #8007675 - AtCoder Beginner Contest 088」 Integer#to_i(2) のリテラル2を再利用するために t の初期値を1から2にしてしまう。つじつまを合わせるために問題由来のビット列 s の方を2倍してしまう。それでは釣り合わないんだけど W の代入文が省けるのと、2倍した s がループの停止条件としてそのまま使えるので総合して得する。■短いソースに何重にも意味を重ねてすべてがすべてと必然的に絡み合う感じ。最適化の極みよな。アルゴリズムと言語と個々の問題に対する深い理解がないとここまで自由にいじくれませんよ。


2019年10月15日 (火) 宇宙ツイッタラーXさんのツイート: "AtCoder Problems を更新しました。難易度推定アルゴリズムが改善され、いくつかの問題で難易度が低めに出ていたものが修正されました。 by @pepsin_amylase"」■AtCoder Problems が推薦する過去問がいい具合に苦しめてくるので時間が溶ける。ここ数日の睡眠不足はこれのせい。とても良い。


2019年10月14日 (月) ガソリンスタンドで見た注意書き。「給油中はエンジンを切りましょう」■思わず「え、そんなことができるの? 給油口を開けたあとですぐにキーを差し直してエンジンをかけるの?」と思ったのだけど、たぶん運転席周りのレバーでぱかっと開けられるのだろうなと気がついた。■プレス機なんかは両手で操作をしないと作動しないような仕組みになってるんじゃないかと思う。「両手操作式安全装置」というのがそうではないか。本の裁断に使っているカッターには「一人で作業するように」という注意書きがある。もともと片手で押し下げられるようなレバーではないので、そういう注意になっている。■給油口を鍵なしで開けられる車はなんと「便利」なんだろう。■最近のキーは鍵穴を必要としないみたい。そういう時代に合った車のインテリジェントさに期待してもいいのだろうか。実際どうなの?■アクセルを踏んだら自動でパーキングブレーキを解除しますよ、ってな「スマートさ」だけは知ってるんだけど。俺は信頼できない自分を縛るために信号停止のたび、渋滞中の一進一退のたびにサイドブレーキを引くんだけど、自動で解除されたら困るんだけど。


2019年10月12日 (土) ちょっとだけGOLFに走った (311 Byte / 60 ms / 1916 KB)」「悪ノリしたが空白を詰めただけでは変態ゴルファーの背が遠い (188 Byte)」からの派生。■俺は「可読性」という言葉を、そうとう眉に唾をつけて見ている。これが「表面的なこと」「主観的なこと」に不相応な大義名分を与えている気がするから。典型例が「条件演算子は可読性が~云々」。絵本しか読めない人間がすべきは決して、「じをよみなれないぼくにもわかるようにもっと *可読性* をたかめてください」と主張・要求することではない。早く読めるようになって最初に内容を議論できるようになるといいですね。がんばりましょう。■たまたま例に挙げたけど、俺は条件演算子が好き。理由もある>20181029。if が値を返さない C++ では使わずに const を徹底できないという理由もある。■俺は可読性が Easy を志向していると言っている。そのように使われがちな現実がある。それでは紛糾するし迷走するから、志向するのは Simple な何かにして、そこから可読性が生じるように仕向けるのが正しい順序ではないか。■Ich! Ich! Ich!■■■たまたま見つけた9年前に書かれた文章。「ソースコードの可読性や保守性:地方からの戯言:エンジニアライフ」■最後の方から引用。保守性については定見はないが、まったくその通りだと思う。「プログラムの組み方、という点においては、私は保守性や可読性というものを持ち出すのは避けるべきと感じています。ある人の基準がそのまま別の人に通じるとは限りません、むしろ経験や思想などが異なることの方がほとんどです。通じないことの方が多いでしょう。そのような状態で議論を続けるのはある種の押し付けでしかありません。それを分かったうえで議論を続けることが建設的ではないでしょうか。個人個人によって大きく意見が異なる保守性・可読性といった指標を用いるのではなく、何か別の伝わりやすく明確な基準、それが何かは非常に難しいかもしれませんが、レスポンスなどの比較的判断しやすい要素が必要なのだと感じます。」■同じ人からさらに。大いに共感する。「誰にでもわかるような仕事:地方からの戯言:エンジニアライフ