/ 最近 .rdf 追記 設定 本棚

脳log[2019-02-18~]



2019年02月18日 (月) すごく好き。「SimpleとEasyは違う / Simple is not Easy - Speaker Deck」自戒すべきは自分で書いたものの複雑さは割り引いて判断しがちということだな。知らず Simple から遠ざかっていってる。Easy は端から眼中にない。それは道具を使いこなせない、対象を理解できない、自分の問題。■■■@2019-04-16 スラドで見た格言。「UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie」 シンプルだから理解できる、イージーであるとは限らないってこと。いいこと言うなあ。


2019年02月12日 (火) 指導役の上司を射殺した警察官の地裁判決。求刑25年が22年になった。前日の新聞を読んだ際に、何の資料もない中ではあるけど、10年以下であってほしいと期待した。■撃たれて亡くなった人も人生のちょうど半ばくらいという若さだけど、撃ったほうもギリギリ未成年(※改正の前後や規定する法律の選び方で変わるが詳しくは知らん)だった。3人の裁判員のうちで同年代の1人が「幼く見えた」「年齢に引きずられず警察官であることを重視した」と語ったらしいのが自分とはきれいな対照だった。■年齢について。成熟段階にある人間の適応能力の高さは自我の不安定さと引き換えであり、未成年の警官を極端な行動をとらせるまでに追い詰めたことの責任の一端を周囲で引き受け、個人に対しては寛容と更生への期待を持ちたい。少年法の適応年齢でスッパリ切り分けられるものではなくグラデーションを付けるのがいい。これまで生きてきた長さに比べて10年間は半分になる。3分の1が刑務所生活になる。十分だろう。それを越えるにしても、15年間というのは想像を巡らせるのも困難な長期であり隔絶された生活がハンデになる。15年がありうる上限だと思っていた。■職業について。あまり多くない警官との関わりの中で知ったのは、警官もただ職に就く世間一般の人間であるということ。「警官だから~」という勝手な期待は、世間一般の人間に裏切られるのと同じ程度に裏切られる。たまたま手の届く場所に拳銃があった不運に同情する材料になりこそすれ、「だからこそ~」という戒めにつなげようとは思わない。拳銃の配備に対する警察への意見も裁判員からあった。■控訴審での減刑に期待する。


2019年02月11日 (月) 「綺麗で遅いコード」はおそらく最初は「汚くて速いコード」のプロトタイプとして存在していた。その後は検証用のテストコードに最適。■RDB に非正規化という手順がある。理論と現実のバランス。


2019年02月10日 (日) アマゾンの「スポンサープロダクト」汚染がひどい有様だ。お金を持ってる販売者を見分けることはできるかもしれないけど、それだけ。アマゾンは自らの検索精度を金で歪め、望みの商品を買いたい客からの信頼を捨てている。■10年以上の付き合いだがめっきり使わなくなった(※)。なければないで特に困ることはなかった。それを気付かせてどないすんの? そうではない人をどれだけ確保しているのか。※理由はトップページからウィッシュリストへのリンクが消えたからなんだけど、久しぶりに開くからスポンサープロダクトの増え方に驚く。


2019年02月09日 (土) 全部読んだ。進捗を振り返りつつですごくわかりやすかった。「ゼロから実装する縦書きTextViewとその周辺技術 / Vertical TextView from Scratch and Related Technologies - Speaker Deck」 Twitter も読んでいたので、スライドとスライドの間を何かの機会ででも読みたいな。


2019年02月08日 (金) auto_ptr 大好きなのでこれは良い。「Rustのメモリ管理って面白い - Qiita


2019年02月07日 (木) Appleは、広告提供者やサイトにユーザーの追跡を行わないよう求めるプライバシー設定が、(皮肉なことに)ユーザーを識別するためのフィンガープリントとして利用可能であるため、同社のウェブブラウザ「Safari」からこの機能を削除すると発表した。」「「Do Not Track」の仕様は理論上は素晴らしいアイデアだとされてきたが、現実にはまったくうまく機能していなかった。」■「理論上は素晴らしいアイデア」<<嘘つけ。最初から見え見えのおままごとだった。俺は送っていない。ただスクリプトを切るだけ>20150702


2019年02月06日 (水) こういう考え方すごく好き。“The fact that some types are atomic, and others are not is dangerous: even if the original code was written by people who knew that volatile int access was atomic, maintainers in future may need to expand that to a volatile long to handle scale -at which point atomicity of access is lost.” だけど自分が「知っている側の人間」だと境界で綱渡りをしたくなったりもする。だから最初から「混ぜるな」「条件を付けるな」ってことだ。それは “dangerous” だと。■以前に自分の言葉でこう書いている。「条件付きの正しさというものを俺は信用しない。条件は見落とされ誤って判断され、正しさはいずれ失われる。


2019年02月05日 (火) バーコードを無効化するというとき、ついバーを横切るように線を引きたくなるけど、たぶん人間が判断するならそれがひと目でわかる印だと思うけど、機械による読み取りを妨害するならバーを隠すかバーの間を埋めるかする方が効果があるはず。■今日長細い白テープでバーが隠してあるのを見た。初めてのパターン。


2019年02月02日 (土) returns the length in characters というとき、NULL 文字は文字にカウントされていない雰囲気(1)。GetWindowTextLength は(常にではないが) WM_GETTEXTLENGTH を生成すると書かれていて、WM_GETTEXTLENGTH の説明では NULL 文字を含まないと明記されている(2)。テキストがないとき 0 を返すということは、NULL 文字が勘定に入っていないことを示している(3)。1、2、3 のどれをとっても NULL 文字が数に入っていると考える理由にならない。厳密に言えば数に入っていることを否定する理由にもならないけども、傾きはある。■仕様は「確保するのに十分なサイズ」だとは言っていない。場合により実際より大きい長さが返ることがあるけど小さくなることはないので、この数字を当てにしてバッファのサイズを決めても良いと言っているだけ。NULL 末端文字配列を作りたい者が +1 するのは当人の都合であり責務である。■■■WM_GETTEXT メッセージのパラメータと戻り値における "including the terminating null character." と "not including the terminating null character." の混在は、一見すると注意力を試しミスを誘うようだけど、バッファとテキストの違いで理解できる。バッファのサイズを指定するとき、NULL 文字が勘定に入る。テキストの長さを指定するとき、NULL 文字が勘定に入らない。これが Windows API 全体で徹底されているかは知らないが、GetWindowTextLength には入っていないだろう。


2019年01月30日 (水)

最終更新: 2019-04-12T22:44+0900

[ProjectEuler] Problem 158

「解けなくて飛ばした問題の中で一番最初の問題」シリーズ。今は Problem 66 なんだけど……解けない。気を取り直してテキトーに興味の持てる問題に取りかかってみたのが Problem 158。Difficulty Rating は Problem 66 が 25 % で、Problem 158 が 55 %。100 % に近い方が難しいっぽい。

#!rubyw
# coding: utf-8

# Classified identity
#
# * p-value.
# * the number of characters that will increment p-value.
# ・ the number of characters that will not increment p-value. (can be calculated)
# ・ length. (counted externally)
# ・ string value and its rightmost character. (no use)

p1, p0 = [0] * 26, [0] * 26
("a".."z").each{|ch|
	p0["z".ord - ch.ord] += 1
}

2.upto(26){|length|
	q1, q0 = [0] * (27 - length), [0] * (27 - length)

	# increment
	p0.each.with_index{|sum, number|
		number.times{|n|
			q1[n] += sum
		}
	}

	# not increment
	p0.each.with_index{|sum, number|
		not_number = 27 - length - number
		not_number.times{|n|
			q0[n + number] += sum
		}
	}
	p1.each.with_index{|sum, number|
		not_number = 27 - length - number
		not_number.times{|n|
			q1[n + number] += sum
		}
	}

	puts "p(%2d) = %12d"%[length, q1.inject(&:+)]
	p1, p0 = q1, q0
}

過去に Problem 191 を解いた経験が生きている。ちなみに Problem 191 の Difficulty Rating は 35 %。


2019年01月25日 (金) [SakuraEditor] #765 #766 PR 本文の不備くらいって言われたけども、それは他者への最低限の礼儀であり必要条件だ。形式や枝葉ではなく核心(PR の目的)がないって言ってんだから当然だ。■内容を判断すればコードを費やすほどの価値がないという結論になる。そもそも価値を示す証拠が提出されていない。1.そこが問題(ホットスポット。ボトルネック)であること。2.アプリケーションで効果を実測すること。3.マイクロベンチマークに基づいて机上の空論を通すとしても、(ExtTextOut への)適用箇所が実験の条件に合致するという言質なり証拠なりがなければ論理がつながらない。そのどれかをクリアするのが必要条件で、でもマージするのに十分な条件ではない。でも必要から十分への間には主観的価値(「多少のペナルティに目をつぶっても記述は少ないほうがいい。API、ライブラリ、コンパイラに仕事をさせるほうがいい」)が含まれるから問わなかった。体裁ぐらい、ではなく、体裁だけでも、だった。ちまちましたことに血道をあげるモチベーションを削ぐこともないと思ったから。■自分にとっての最適化、リファクタリングのひとつは MyFillRect のような無駄を取り除くことにある。既存の道具を使わない理由がない。だって FillRect はボトルネックでも使ってはいけない罠 API でもないでしょう? そうして非本質的なコード、絡み合って生じた無駄な処理を省いていけばエディタとしての本質、不可欠な処理に集中できるし、コードサイズ(メモリフットプリント)が減れば、コードパスが短くなれば、一般に速度の向上が期待できる。頭を悩ませるトレードオフは存在しない。■■■CGraphics クラスのチューニングとしての MyFillRect はやって悪くないのかもしれない。グローバル名前空間に FillRect と併存するものでなく、CGraphics::FillMyRect の実装の工夫としてなら。CGraphics 利用者と実装者の間では関心の分離がなされているし、CGraphics のような間接クラスには利用に当たってオーバーヘッドが最小限となるような非機能要件があるだろうから、速度を追う理由がある。■でもこういう大枠で合意することはできないだろうな。だって未だに「速度は(主たる)理由ではない」って言うんだもんな。たしかに最初から「速度は障害にならない」というような言い方をしてるんだけど、でも、だったら何なのかをさっぱり語らない。「悪くならない」「障害ではない」「再考する」「置き換える」は変更の理由ではない。満足できる理由ではないってんではない。行動を説明する理由や目的としての体をなしてないってんだ。でも筋が通らないままマージされた。これが誤算。無理が通るなら俺は狂って死ぬ。


2019年01月24日 (木) 病気を自認して都合のいい言い訳とすることは警戒すべき傾向だけど、でも、面白いことが書いてあるんだよなあ。「自閉症 - Wikipedia」 あれもこれもそれもどれも、誰にでも当てはまることが症状として書かれてるんじゃないかなあ。そりゃオレオレアスペが流行るはずだ。