2017年11月29日 (水) 「ニュース解説 - できの悪いソースコードをAIで発見、富士通が不採算案件の抑制へ：ITpro」■たたきコメント安定。でも熟練プログラマが嗅ぎつけるコードの不吉な臭いってやつはある程度認めるんでしょ？ たぶんアクセスパターンも重要な兆候だと思うんだけどそれは視野に入っているだろうか。CHANGELOGでもないのにちょこちょこちょこちょこいろいろな人が手を入れるファイルは分割の仕方、つまり設計のミスを臭わせるとかバグの温床になってるとかそういうの。■しかし、AIに下読みしてもらうのが助けになるというなら、現実は想像よりもウンコードとの遭遇確率が低いということで間違いないのでしょうか。ないのですか？
ツッコミを入れる
2017年11月28日 (火) 「Xi / Musicarusさんのツイート: "バーガーキングの「直火グリルをこんなことがあっても続けてます」ってアピールしてる広告、これがオフィシャルの広告とかパワフルすぎるでしょ https://t.co/2OkoN9UtVw"」■人に勧められて一度だけ食べた。店がないから一度だけ。印象は、モスバーガーと違ってマクドナルドと同じ土俵にいるな、と。だけどあらゆる点で一歩だけ上にいるな、と。だからマクドナルドが価格を近づけてる今、店があればバーガーキングを選ばない理由がない。■直火焼きというのは日本でもそうなんだろうか。もうひとつ印象に残ってるのが、口に頬張ろうとするときにふっとのどから鼻に抜ける、炭っぽいというか灰っぽいというか野趣のある風味だったので。それは２口目も３口目も変わらなかった。もう一回書くけど、店があればあえて１個300円、490円のマクドナルドを選ぶ理由がない。モスには行く。あれはやっぱり日本のチェーンであって、見てる方向が違うしそこが合う(※べつにエビとかコロッケとかライスとか海鮮とか名のつくものを買うわけではないので、どこがって問われると困るのだけど)。それにハンバーガー２個を単品買いする自分にとって、マクドナルドより安くなったりもする。■店がないというバーガーキングはピエリ守山の中にある。廃墟だっていうからどんだけへんぴな立地なのかと思ったら、琵琶湖大橋の付け根だっていうんだからわからない。橋っていうのはボトルネックになるほど人が集まる場所ではないのか。検索したら yuzuru0024さんの分析がおもしろい。「滋賀県巨大ショッピングモール「ピエリ守山」はなぜ失敗したのですか？ - ... - Yahoo!知恵袋」 地元の市街からは遠く、田舎を目指す人や都会を目指す人にとっては境目・中継地点であって、長居する場所ではないと。■夜に行ったんだけど駐車場に30cmくらいの高さのハードルが林立してるんだよね。低くて横長の車止めみたいなの。空を見て歩いていたのが悪いっちゃ悪いのだけど、夜でもあり視界に入らない低さでもあり、あれはトラップである。そんなのがごろごろしてる。よくよく足下に注意して歩かないと俺みたいにもんどりうって背中から着地することになる。ニーシンガードと胸部・背部プロテクタが初めて仕事をした瞬間だった。びっくりしたけどどこも痛くない。
2017年11月27日 (月) PDCAサイクルという言葉を聞いたことがある。そういうレベルで知っている。さて、なんの略だっただろう。たしか、PLAN、DO、C(スィー)、ANALYZE？■Cだけ分からなかった。実は Aも間違っていた。■CHECKなんて「要素に対して加工処理を実行します - function elementProcess(elm)」なんてのと同列の命名ぽくて、鼻で笑われそうで怖いんだけど。■「チェックします！ チェックしました！」「おい、全然だめじゃないか。ちゃんと確認したのか」「はい、確認しました。問題ありません！」「……」みたいなナンセンスを許容する単語だから避けた方がいいって聞いた。
2017年11月26日 (日)
「Color Emoji (DirectX support improvements) by koron · Pull Request #2375 · vim/vim」■gui_dwrite.cppだけ読めば知りたいことがわかるって正しいありようの結果だよね。GDIを切り捨てないで "extremely" に改善したというパフォーマンスの出所 とは。IDWriteBitmapRenderTarget が用済みにされ代わりに CreateDCRenderTarget から取得されているレンダーターゲットがそうだろうか。■「Direct2D と GDI の相互運用性の概要 (Windows) (msdn.microsoft.com)」から抜き出す。「Direct2D と GDI を組み合わせるには、2 つの方法があります。」方法の１が例の CreateDCRenderTarget>「Direct2D コンテンツを GDI DC に描画するには、ID2D1DCRenderTarget を使用します。DC レンダー ターゲットを作成するには、ID2D1Factory::CreateDCRenderTarget メソッドを使用します。」方法の２>「GDI コンテンツを Direct2D GDI 互換レンダー ターゲットに書き込むこともできます。GDI コンテンツを Direct2D GDI 互換のレンダー ターゲットにレンダリングするには、ID2D1GdiInteropRenderTarget を使用します。」えっと、IDWriteGdiInterop の CreateBitmapRenderTarget から取得される IDWriteBitmapRenderTarget さんは何処 ？ 亡き者？■色絵文字の描画は TranslateColorGlyphRun でグリフランを色別に分解してループで順番に描画していくのかな。うまいこと既存のスキームに落とし込むもんだ。なんか最近プラットフォームごとの対応を比較する記事を読んだ気がする。DirectWriteが一番まともとかそんな風に評されていたような。これこれ、TATEditorの人>「カラー絵文字〜OpenTypeフォントの仕様を中心に〜 - Qiita」なんかよくわかりませんね。プラットフォーム固有は Windowsに限ればいいだけのことだけど、フォントがポータブルではないの？■中と外の間に立って何を外に見せるのか。ただ内部の下請けにスルーするだけのメンバーであるとしても、それを間に立つ自身の仕様の一部とすることには決定が伴うと思う。それができなかったときに、公開メンバ変数のメソッドを呼ぶというようなアンチパターン(someObject.memberObject.method() みたいなの)が出現するのだろう。「超優良」なパッチを読んでの感想です。<皮肉じゃないよ、その逆。■「カラー絵文字パッチ制作の経緯 — KaoriYa」からのキーワード>「Flush」「Bind」「リリースエンジニアリング」■「ID2D1DCRenderTarget インターフェイス (Windows) (msdn.microsoft.com)」のソースが読みたいなー。「クライアントの最小要件｜Windows 7, Windows Vista SP2 および Windows Vista 用のプラットフォーム更新プログラム」更新プログラムで Vista が対応している！ なにげにきちんと翻訳された日本語ドキュメントが整備されてるのもありがたい。いずれにしろ程度問題だけど、機械翻訳ではほぼ英語で読んだ方が早いし、英語で読まないと結論にたどり着けないことが往々にしてある。
2017年11月25日 (土) ネット経由の京都新聞で結果を知る>「母なる琵琶湖に浮かぶ島 滋賀県の図柄入りナンバー決定 : 京都新聞」 候補はこんなんだった>「滋賀ナンバー図柄、どれがいい？ 国交省が４案 : 京都新聞」■図柄も色もうるさくなく、順当な結果だと思う。次点は１かな。ごちゃごちゃ詰め込んでモチーフもナンバーもよくわからんなんて最悪の結果にならなくて良かった。
2017年11月24日 (金) 「そうね、パソコンって使いにくいワープロかもしれないね。(20170315)」なんて調子こいてるやつもやっぱり自分でコンピュータの限界を定めているのだと、こういうのを読んで自戒する>「「ディープラーニング×きゅうり」の可能性に、たったひとりで取り組むエンジニア - GeekOut」■ディープラーニングどころかエクセルの回帰なんたらも使えやしない。プリントする以外の出力装置が自作できる？ できない。そのプリントにしても、3Dプリントのための CADソフトだって使ったことがない。いつかのためのブックマークだけしてる(何というソフトがあるのかさえ知らないから)>「一般人が使える3D CADソフトもここまで進化している（Fusion360入門セミナーに参加しました） | スピード狂の自作マニア」←バイクのカメラマウントを考える際に参考にさせてもらったところ。
2017年11月23日 (木) 「最強装備が初期衣装のマイナーチェンジ版みたいなゲーム」■初期パーツが Zenith で最終パーツが Zenith V だったフロントミッション(1st)とか。機動力のためにキャタピラや四本足を一時的に選ぶことはあっても、それで終わっては善玉や主役は張れませんから。スペックを伴って Zenith が帰ってきたときの安堵たるや。
2017年11月21日 (火) 「医者から「母の死亡時刻を安いデジタル時計で決められた！」って許せない？賛否両論の意見が集まる - Togetterまとめ」■まとめコメントには出てきてたけど、そうなんだよね。ブランドっていうより腕時計ってとこで、死亡時刻ってその程度の精度なんね、とりあえず書類を埋める必要があるんだろうね、という納得をしたのだった。
2017年11月17日 (金) [Vista] インターネットオプションの詳細設定のチェック項目全てのラベルが「HTTP 1.1 を使用する-ON」「SSL 3.0 を使用する-OFF」みたいに、ON/OFFで終わるようになっていた。突然に。たぶん音声合成(ナレータ)の設定が影響してるんだろう。たしか Webではチェックボックス・ラジオボタンとラベルの前後関係が、アクセシビリティの観点からどうあるべきか規定(推奨)されていたと思った。きっちりしてるなあと思う反面、最近の Windowsではどうかなあとも思う。7以降はキーボード使いすら見落とされてると感じるから。■■■Windows 10. アップデートのたびに共有が壊れるし、今度はスプーラサービスを利用してない？プリンタの印刷までできなくなった。くだらんおもちゃに成り下がったよな。最初からそうだったと言えるほど他を知らないし悪印象もなかったけど、今ははっきりダメ。ダメな Windows Updateを強制するのが輪をかけてダメ。PCは MSのコンソールではない。Xboxと勘違いしてるんとちゃうか。
2017年11月15日 (水) 表示は HTML+CSSが一番よく知っていて使いやすい。A4に印刷できるし、印刷しなければリンクをクリックもできる。TABLEタグのグループ(table/thead/tfoot/tbody)がパジネイション(※カタカナではわからん。ヘッダ・フッタがページ分割に対応してるってこと)にも対応していて使いやすい。■悩むのがデータソース。永続データではなく表示のための中間データ。XMLをソースにするなら XSLTが使えるが、XMLはファイルに保存するには冗長だし、XSLTはちょっと遅い。IE(※互換モードでも可能だが10まで)+TDCなら TSVファイルをソースにできるが、古いバージョンの IEにロックインされてしまう。Webブラウザがインターネットへの窓口だからか HTMLはローカルのリソースからきっちり切り離されていてデータをつっこみにくい。それだけのためにサーバーは立てない。SCRIPTタグで読み込める JSONは XMLと同様に冗長。その冗長さが無用の可変性を持ち込むことに耐えられない。SQLの INSERT文はテーブル名とオプションの列名を記したあとは、値の組をいくつも羅列できて冗長さがない。というわけでよそから引っ張ってきた生データを最初は XMLファイルに保存していたが今は INSERT文として SQLファイルに保存している。XML+XSLが担っていたデータソース＋表示のための加工を SQLでやってる。■で、本当に悩んでるのが SQLiteから HTML+CSSへの橋渡し。sqlite3.exeがいろいろな出力モードを持っていて、HTMLの表にしたり、CSVにしたり、ちょっと工夫して JSONにしたりはできるんだけど、凝った表示をしたくなれば HTMLは HTMLファイルに書きたいわけで、sqlite3.exeが受け取る、SQLがメインのバッチファイルに HTML片を埋め込むのがつらくなってきた。なんなら HTMLを通して表示したいものを指定するパラメータを渡したりもしたいわけで、HTMLからどうやって可変性のある SQLをつついてその出力を埋め込むのか、その方法を考えてる。XSLTだとブラウザ(※Firefoxと IE)がローカルのデータソースへのアクセスとパラメータの受け渡し手段(XSLTProcessor/ActiveXObject("MSXML2.FreeThreadedDOMDocument.6.0")/XMLHttpRequest)を JavaScriptに対して提供していた。でも今は XMLより SQLをソースに使いたい気分。JSON+Template Literalsが落し所かなあと決まりかけてるんだけど(20171114)、JSONへの不満はもう書いたし、HTMLを JavaScriptの文字列として扱うことにも不満がある。こういう不満ですよ>「非表示の div要素の内容として JSON形式で全ページの HTMLが入っている。(20170906)」 なんでもできるよりそれしかできないの方がよっぽど価値がある。E4X(※今はもう亡い)をテンプレートにできなかったのかな。■なんだかんだ HTMLは孤立していて使えないし、IEはそれを補完して使えるやつだったし(TDCもそうだし src属性を持つ xmlタグもそう)、Firefoxも使える。Google Chromeはローカルリソースがまったく読み込めなくて使い道がない。Headless Chromeは Webブラウジングの、内部からではなく外部からの自動化に役立つかとちょっと調べてみた。アクセスに URLではなくクリックを要求してくる無駄に作り込まれたサイトに対処するために。内部からっていうのは、最初に(主にテスト目的の)アドオンを内通者としてインストールするとか、ユーザーが実行をトリガーするかしないといけないことを指す。ブラウザが認証情報を持ってるのがネックなんだろうけど、プライベートブラウジングモードでもダメなのか。■■■@2017-11-20「Shadow DOM (www.tohoho-web.com)」 template要素と slot要素。データアイランド(ただし可視)に Shadow DOMを関連づけてその配下にテンプレートのコピーを appendすると slot要素と slot属性が結びついているように見える。まず Firefoxが対応していないし、スクリプトでの逐次操作が必要そうだし、すでに完成していて新しいプログラミングパラダイムを見せてくれる XSLTの方がよっぽど使えるという印象。MDNのサンプルではユーザー定義要素とそのコンストラクタで forループを解消してるけど、そこまで要求するならサーバーサイドで動かすことしか考えてないのかな。Shadow DOMにおける slot要素は別々のものを必要に迫られたからなのだろうけどアドホックに雑ぜ雑ぜ(「混ぜ混ぜ」とは変換できなかった)してみただけに見えて、頭の中でモデルをイメージできない。それが自身の知識の不足ゆえであれば問題ないが、高次の構造の欠如によるのであれば使えない技術ってことになる。アドホックというのは演繹が働かず発展性がないということとほとんど同じ意味。■MS用語なのだろうか「XML データアイランド (msdn.microsoft.com)」 必要に応えて問題に対処する手段を提供していたマイクロソフトと、選択肢を奪った不可避の Windows Updateで問題を生み出し足を引っ張る現在のマイクロソフト(20170422, 20171117)。■■■@2017-12-26「ブラウザのしくみ: データ構造とアルゴリズムと雰囲気で理解する DOM と Shadow DOM — hayato.io」 slot要素は出てこない。ツリーのツリーをひとつのツリーに均す(flatten)過程に現れるのだと思うがそこは「魔法」の一言で片付けられた。「ツリーのツリー」は普通の木構造だろうか。ツリーを構成するノード(サブツリーのルート)の背後にまた別のツリー(Shadow Tree)があるのをなんと表現するか。■多重化されたツリーの図が Shadow DOM の本質なのだろうか。だとしたらデータバインディングに使うのは効率が悪い。データ(Shadow Tree)にも表示用テンプレート(Light Tree Node)にも定型が与えられない(=柔軟性がありすぎる)のだから。■「Shadow DOM (w3c.github.io)」 あ、反対だ。表示用テンプレート(Shadow Tree)とデータ(Light Tree Node)の組み合わせが正しい。Shadow Treeに多様性が不要なときに template要素をクローンして使えばいいのか。しかし HTML要素とその slot属性で与えられるデータが不定形だし視覚要素が全く無駄だし、そこにデータを置きたくないし。Shadow DOM ってビジュアルをアタッチする手段なのか？ 俺はデータをアタッチしたい。■「コンテンツはドキュメントに、見た目は Shadow DOM にあります。(www.html5rocks.com)」 HTMLを XMLだと思えばいいだけなのかな、かな？ それでは「すでに完成していて新しいプログラミングパラダイムを見せてくれる XSLTの方がよっぽど使える」という感想が覆らないなあ、自分の用途では。
2017年11月14日 (火) [javascript]「Template literals - JavaScript | MDN」■データとテンプレートを別々に用意して、好きなタイミングで任意のデータに基づいてテンプレートを評価するには？ Answer「I assume the best way to do this is quite obvious, simply reverse the situation given by the question. You just need to wrap the template literals in a function, and then you will delay evaluation until you pass in the desired params. It's that simple.」 残念なのは関数が JSON形式で持ち運びできないことか。
2017年11月10日 (金)
最終更新: 2017-11-22T15:17+0900
♪ 面白かったのでつい。この状態で送られてきた、シャツが。アイロンかけよ、って言われそう。
９年前に初めて自分で買ったシャツを気に入って(あたりまえ)、襟がすり切れても着ていたのだけど、この前、肩胛骨のあたりが縦に15cmほど裂けているのに気が付いた。その代わりがこれ。同じものが手に入るなら同じものを買っていた。サイズは既知だし気に入ることもわかってる、リスクゼロの選択なのだから。
これはダメな思考の典型らしいけど、服を選ぶのに TPOや組み合わせなどなく、ただ１番２番３番の順序だけがある。１番の服があるのに２番の服を着る必要ある？ ない。２番の服があるときに３番の服の出番がある？ ない。１番の服がまた着られるようになってるのに４番の服を着る機会が存在する？ ない。極論すれば１番の服が３着あればいい。テツの黒シャツ。実際はレイヤーとパターンごとに２から３着。年中半そで１枚ではいられない。
裂けたものはアイロン接着の補修布で手当てしたので(しつこい)、結局シャツが１枚増えただけ。経年劣化だとすぐに、とくに補修した周辺がまた裂けそうだけど、そのときまでは。