_ 本年もよろしくお願いいたします。
_ 仕事をしているときは仕事をしている時間を中心に生活を成立させざるを得ないわけなので 制約が多い分かえって出来ることは限られているとも言えるし、あまりぶれた生活ということにはならない。 そんな生活をずっとしていたので連続で休むとその無軌道ぶりによって 暴飲暴食をすることになり、結果としてかなり体調が悪くなる。なので2日休んでもう限界だああと 思って仕事を始めた。
_ 出たら出たでいろいろとらぶっている/いた件が山積しており、2020年もよっぽど気を確かに 持っておかないとあっという間にろくでもない一年になりそうだぞ、と引き締まる思いだ。
_ この手のイベントに参加しようという発想がない人間としては なるべくこの騒ぎから離れたいという気持がどうしても出てきてしまう。 とはいえ都内に住んで都内に勤務している人間なので日々の生活に何らの影響もないということは ないだろうということも予想している。
_ ではどのくらいの影響があって、どのような回避策をとることができるのか、というと、 そもそもオリンピック・パラリンピックがどういう日程で行われているかすら理解できていない 状態では考察のしようがない。あと会場がどこなのかも理解していない。 まあそのあたりは公式サイトらしきものやWikipediaを見ることである程度理解できたものの、 それはあくまでオリンピック・パラリンピックの日程であって、それによって生じる 生活の変化、具体的には交通機関や宿泊施設への影響、主要商業施設への影響、 あと、観光地への影響というのが、量的なものも、期間的なものも想像ができない。 そういう目安をどこかが示しているのかというのも分からない。少なくともまとまっているところは 見当たらなかったので、自分でいろいろ情報を集めないといかんのだろうか？と思っているところだ 。
_ ひとまず期間としては7/24〜8/9がオリンピックで、8/25〜9/6 がパラリンピックらしい。 ということすら知らなかったので、この周辺を中心に日常生活の影響が出るという感じだろうか
_ 連休も最終日か。あっという間だった。予定通り9日中6日はしごとをした。思った以上の 成果があった…!!! とは言えないのがなさけないが、しかしまとまった時間をとらないと 進まないタイプの内容で進展があったのは喜ぶべきことだと思う。 あとF#の学習も少し進めることができたのもの大きい。
_ 連休最終日の夜の寝苦しさが過去有数のもので、暑い…のは洗濯物を干すために エアコンをつけていたからだが、それ以外に、間断なく襲ってくる吐き気と戦っていた。 これは新春恒例の食中毒か？ しかし別に思いあたるものがない。寝る直前に ステーキなんてものを喰ったので胃もたれだろうか？ せっかく高いステーキを喰ったのに 胃もたれぐらいの理由で吐いたらもったいないので我慢する。 吐き気は昼前まで続いた。その後、腹を大きく下したわけでもないので、 本当に胃もたれだったのかもしれない
_ そんなことがあったのでもう無茶な物の食べかたはできん…ということを思い知った。
_ O'Reilly Leaning で読める本をたくさん読みつつ WikiBooksを読んだ。
_ 関数型言語はErlangでけっこう慣れたつもりなので、再帰だとかパターンマッチングだとかは 特に戸惑うところがない。 そしてSystem.〜〜 みたいな Base Class Library は C# で15年くらい 使いつづけたわけなのでこれも問題ない。だいたい新しい言語や環境の習得にあたり ベースになるライブラリのなんたるかを把握するというコストは決して低くないことが常なので、 それに比べるとF#のハードルはかなり低い。 書きづらいところはC#に逃がすとか、Cで書いてP/Invokeするなんてのも、 やろうと思えばできるわけなので、そういう点でも入りやすい。
_ 今まで触ってきた関数型言語というと、ErlangやLisp系がほとんどなので、 動的型付けというやつばかりだ。静的型付けの、いろんな型を作りながら プログラムを書いてゆくという行為は今までやっていなかったのでいろいろ新鮮だ。 よく言うと新鮮だ、という方が正確かもしれない。迷いの元でもあるので…
_ The Functional Toolkit - Scott Wlaschinというプレゼンがとてもためになった。 Scott Wlaschinというひとは 同じような切り口でいくつかプレゼンを上げているのでそっちも見てゆくと復習にもなってよい。 Domain Driven Design というやつを F# で実践する書籍 (Domain Modeling Made Functional) も出しているようだ。これは O'Reilly Leaning で読めるのであとで読む。
_ Computation Expression についても少し理解できてきた。 それまでは、名前しか知らなかったのでプログラムのどの部分にそれが使われているの？ ということを理解していなかった。たとえばC#で <T> というようなものが見えればああgenericsなんだね、ということが分かるし、 Erlangで [ X || 〜〜 みたいな記述を見掛ければああList comprehensionsだね、ということが 分かるわけで、一方Computation Expressionとはどういう見た目をしているもんなのか？ ということが分かっていなかった。のが、分かるようになった。 WikiBooksを読んでから、 Computation expressions: Introduction | F# for fun and profit を読んで、 ああそうやって作るもんなのねーということが分かってきた。 分かってきたので、 公式のドキュメントも、けっこう分かるようになってきた。 あらためて読んでみるとこの F# Documentation というやつはとてもよくできている気がする。
_ F# Snippetsも、読めるものが増えたような。 FSharpPlusは、 今のところBoostに関わっているときのような印象を受けてしまい素直に読めない。 「のような」と言っておきながら、 そもそもBoostに関わるとどういう印象を抱くのかを説明したことがない気がするが… まあわかりますよね (無茶言うな)
_ F# を知ってほしい - Qiita は、F#のことを 要領よく説明してくれており大変に便利だ。1日1回は読もう
_ WikiBooksのComputation Expressionsの説明の中に出てきた用語。 WikiBooksの説明によると、問題を解くためのDSLを作って、その後にそのDSLを使って 問題を解いてゆくようなものらしい。 Computation Expressionsはそういったプログラミングのためのツールとしても使えるんですよ、 というお話のようだ。
_ 写真の角度のせいなのか、キーボードのストロークがかなり浅くなった？ ように見えないこともない。Portégé という名前はずいぶん懐しく感じるけど、 海外ではそういう名前のままだったのだろうか。国内でも出るのだろうか？ プレスリリースは usにはあるけど国内のものはない。
_ で1.92ポンドって何グラムなんだ？ …… 870グラムらしい。 これはすごいな
_ 昨晩は妙に寝付きが悪くフトンに入ってから4時間くらい眠れなかった。 連休中はそこそこ寝ていたし、前日7時間ちょっと寝ていたのですでに 睡眠時間としては十分だったのだろうか。酒も飲んでないし。それならそれでいいが ようやく眠ることができて朝起きたら結局眠いのでよくわからない
_ 結局正式名称がよくわかっていない。Safariとはもう言わないようにも見えるし。 そしてアプリの名前もよくわからない。アプリ情報を見ると「O'Reilly」となっている。
_ で、デスクトップPCではブラウザ経由で、スマホではそのアプリで読むことが多い。 Coders At Work は、別にスマホでも十分読めた。でもソースコードや図表が多い 書籍だとちょっと厳しいかもしれない。アプリはiOSとAndroid用しかないようだ。 Fireでは、まあ無理矢理入れれば入るのかもしれないが無理矢理なことはあまりしたくない。
_ となるとPCでがんばって読むか、タブレット…ということになるんだが、もともと 関心の薄いAndroidタブレットなんて今更買う気がしない… Apple製品も今更触りたいとは思わない… ので、つまりどうしたもんかなと思う。 スマホのアプリはそんなにすばらしいものだとは思わないが、 しかしそれなりに便利なので使ってゆきたい。
_ …Fireでブラウザから見るという手があるか。しかしこの機械はWifiしかつながっていない。 Bluetoothテザリングはできないようだ。スマホとペアリングはできるけど、 Object Push Profile (OPP) しか生えてこない。 Wifiのテザリングはできればやりたくないしなあ
_ Fireも、利用を再開してから半年以上経過して、さすがにちょっとくたびれてきたかな？ という気がする。それでも充電は2日に1回くらいのペースで十分だし大きな問題はない。
_ ……当面はLavie Tab W でやればいいのか。 あれならWindows10なので普通にBluetoothテザリングもできるはずだし… FireはFireで持ち歩きたいのでタブレット満載のカバンになってしまうが仕方ない。
_ F# InteractiveやJupyterでF#のことにも少し慣れてきた気がしたので、 お題も決まっていることだしさっそくプログラム書くか… と取り組んでみた。 ネットワーク越しのzipファイルのキャプチャファイルの…というやつだ。 まだ50行ほどしか書いていないが、ネットワーク越しのファイル/ディレクトリを泳いで zip解いてpcap/pcapngを露出させるところまでは書けた。
_ まだ目が慣れていないせいかF#のソースは構造が見えづらい。なんか記号が少ないというか、 英単語だらけという印象が勝ってしまい、インデントで構造を見分ける力がまだついていないようだ。 つまりごちゃごちゃした感じを受けてしまう。Pythonと大差ない見た目のはずなんだがなあ〜 Pythonはコロンがいい感じの仕事をしているのだろうか
_ さて昨日も書いた通りBCL側はよく分かっているしよく分かっていない部分については 調べることもできている。関数型言語の基本的なプログラムの書きかたも分かっている。つまり Erlangならこう書くだろう、というようなものだけど。そして sequenceやcomputation expressionsのことも分かってきたのでサンプルプログラムで そういうのを使われても理解が止まってしまうということはない… ということで、まだ50行ほどとはいえプログラムを書く際に手も足も出ないということはなく、 書きたいものを書きたいように書くことができている。 ただそれは、今の知識で書けているというだけなので、F#らしいプログラムなのかどうかは よくわからない。
_ F#らしいかどうかはともあれ、すぐに書き始めることができる程度には馴染むことが できているということなのだと思う。もっとよい書きかたがあるとは思うが、 書いている最中に強い悩みを抱かせるような、今書きあがったものに対する物足りなさ といったものはないので、新しいことを覚えたり、他の人のソースから学んだりしてゆくことで 段階的によいものにできるんだろうなあ〜という気がする。 そういう点でも私には馴染みやすいのかもしれない。
_ この、「最善かどうかは分からないけど悩むほどひどいとは思えない」という境地は私にとっては わりと重要で、これが、「正しいとは思えないしすぐに破綻しそう」というレベルになると 私の中ではブレーキがかかる。「悩むほどひどいとは思えない」は錯覚かもしれんが、それでも その心境は先に進むのに邪魔になるわけではない。
_ あまり期限がきびしくない、使い捨ての.NETベースのアプリなんかはもうF#で書いてしまっても いいんじゃないかという気がしてくる。あとPythonのスクリプトで書いていたものとか？ とはいえPythonはやはり周辺モジュールが充実しているという現実があったりもするので 常に代替できるかどうかは分からんが… 次節につづく
_ ざっと調べただけでも6つくらい見つかってしまった。 libpcapのラッパーになっているもの、managedのもの、 キャプチャファイルを操作するだけのもの、などなど。
_ あと、pcap/pcapngのフレーム構造だけを相手にするものと、中のEthernetフレーム、 IPパケット、TCPパケット、なんかを解析して扱いやすくしてくれるもの、という 違いも、それはそれであるらしい。たしかにpcap/pcapng固有のフレーム構造さえどうにか できれば、中のデータはEthernetフレームそのものなのだから、そこから先の 構造をpcap/pcapngいじりするライブラリが面倒を見る必要はかならずしもないのかもしれない。
_ ではそういうパケット解析ライブラリはというと… これはこれで何種類かあるようだ。 PacketDotNetがよさそうに見える。 この手のライブラリは内部構造を表現するためにバイト配列のコピーが発生したりすることが多く、そういうライブラリはかなりメモリ負荷が高くなるので好かんのだけど、 このPacketDotNetというのはそのあたりをかなり気遣って作られているようだ。 そしてこれは同じ人のSharpPcapというライブラリから分離したものらしいので、組み合わせて使ってみようと思う。
_ ……むむむ、SharpPcapは中でlibpcapを使っているようだ。なのでSystem.IO.Streamのまま 解析させるといったことはできないみたい。 PCAP-NG File Readerというやつに乗り換えてみた。 これでペイロードが手に入ればあとはPacketDotNetはそのまま使えるはずだ…
_ さて PcapngFile に DeflateStreamを与えてみたら怒られた。 どうやら中でSeekしているらしくそれをDeflateStreamがサポートしていないらしい。 では乗り換えだ…というのもどうかと思うし、後で読み込みを並列化させる際にどうせ アーカイブファイル内の圧縮ファイルはひとつずつメモリに展開することになるので、 そのような処理を追加することにした。
_ でStreamクラスを眺めていたらCopyToというメソッドがあった。 Goのio.Copyを見てうらやましいと思ったもんだが、BCLにも同じようなのがあったとは。 あれ、こんなのあったっけ… どうやら .NET Framework 4.0 から追加されたものらしい。
_ (注: この段落以降のサイズが云々という話は全部勘違いなので注意。解決編は1/13にある) やったね、と思いながらDeflateStream→MemoryStreamにCopyToしてみたところ… なんかおかしい。調べてみると MemoryStream.Capacity が実際の生ファイルの サイズよりも随分小さい。 268435456 らしい。これは何かの倍数なのかな？ とWolfram Alphaに聞いてみたところ 2の28乗らしい。つまり256MiBらしい。いかにもマジックナンバーっぽいやつなので 何によってそうなっているのか… というと、今の私にはRef12があるのでそれを 調べることができるかもしれない。
_ Stream.CopyTo そのものは内部でバイト配列持ってコピーしてるだけだった。 デフォルトでは80KiBのバッファを一時的に確保してコピーしているらしい。で コピー先のWriteを呼んでいるだけだった。となると256MiBで止まっているのは MemoryStream側の都合ということになるのかなあ？ 実際この状態で WriteByte(0x00) などとしてもだまって返ってきてCapacityは変化しない。
_ MemoryStreamのEnsureCapacityというprivateメソッドでサイズの拡張をしており、 こいつを見る限りでは Array.MaxByteArrayLength までしか拡張しないようになっている。 Array.MaxByteArrayLength は 0x7FFFFFC7 だそうな。ということは2GiBよりちょっと 少ないくらいか… じゃあまだぜんぜんいけるじゃないか。 とはいえ内部表現がバイト配列である以上は超えられない壁が意外と近かったという話でもある
_ Visual Studioは32ビットアプリなのでvshost経由で動かしているのがまずいのかねー と思いつつ外で動かしてみたけど同じ結果だった。
_ MemoryStreamの代替を目指しているモジュールは、それはそれでいくつかあるようだ。 いくつか評価しようとしたところで時間切れになってしまった。
_ 昨日の反省を元に再度さっさと寝てみた。今回は睡眠時間も十分にとれたはずなのだが、 起きたときに異様にだるかった。カゼか？ というと別に鼻水が出るわけでもないし 喉が痛いわけでもない。頭痛やセキも、ないとは言わんがいつもある程度だし… 昨日は早めにめしを喰ったし酒も飲んでないので、そういう点でも睡眠にとっては よい環境だったはずだが…
_ なんだかんだいって、節制をしていれば体調はよくなるもんだという 幻想がまだあるのだと思う。若いうちは実際にそうだったのかもしれんが
_ 昨日の件からは少し離れて、P/Invokeをいじる。 コールバックはdelegate作ってやる、などもとくにC#と変わっていない。 LPTSTR なんかを受けるときはStringBuilderを使う…というのも同じようにできたんだが、 これでいいのかしら？
_ Visual Studioでいじっていると、F5押してから実行が始まるまでに、C#のときには 感じなかったタイムラグが存在する。数秒程度とはいえちょっと気になる。 一方fsi.exe (インタプリタ) ではそういうひっかかりはとくにない。 スクリプト言語として使ってもなかなか強力だ。
_ 一方でP/Invokeを中心に書いてゆくのはいまいち楽しくない。 C#なら楽しいかというとそんなことはないので、結局F#で書くことになるが… なおPINVOKE.NETはF#のコードは ないみたい。別に自分で書けばいいのだが… このサイトの存在を知ったのは今年に入ってからなので、 今まではずっと手で書いていた。
_ IntPtrはnativeintというやつで扱うことができる… そして nというsuffixでnativeintを作ったりもできる… ので、 IntPtr.Zero は 0n でよいみたいだ。一方で == NULL みたいなやつの書きかたが わからない。nativeint は == とか === で比較することはできないようだ。 どうしたもんか…正解とは思えんがIntPtr.Equals を使って回避。 構造体のポインタを渡してGetWindowPosなどもとれるようになった。
_ ……… 比較は == じゃなくて = だった。恥ずかしすぎて漏れそう
_ BluetoothテザリングをしてChromeで本を読んでみた。 もちろんそれ自体は可能だったんだが、使い勝手が非常に悪かった。 何かの操作をして、その結果が反映されるまでに時間がかかり、しかもその間 固まる…わけではなく、普通にスクロールやらなにやらをできてしまう…という状態。 何秒〜10秒以上前の何らかの操作の結果が、別のレスポンシブな操作の途中で 反映されることになり、しかもその「操作」がいくつか並列で行われてゆくと、 結果としてよくわからない理由で画面がころころ変わる、ようにしか見えないという混乱になってしまう。 非同期で通信して結果の反映も非同期で来るというような作りの場合、 当然だけど通信はわりと速く終わることが前提なんだろう〜 なお文字のサイズを変える コントロールがなぜか反応しないというのも地味に困っている。色合いとかを変えるボタンは 反映するんだが、文字の大きさや行間隔の調整をするスライドバー的なものが押しても 反応しない。
_ これでは少しきついな。どういう操作がどういう遅延の後に反映されるのか、というような 感覚がついてくれば、遠隔操作だとか先行入力みたいなもんだという割り切りで つきあってゆくことができるのだろうか。
_ 何かの操作が受け付けられたかどうかのフィードバックがまったくないのが そもそもの問題なのかもしれない。それに引き続き、裏でなんかやってます、という アピールもほとんどない。
_ 前回は使いもんにならんくらいの勢いで書いてみたものの、今日再度試してみたらまあ 読み込み中であることを察してこっちが待てばいいというだけの話なのかもしれない…という程度の感想に変化した。
_ そういったあたりを心理的にクリアしてみると、そこそこのサイズできちんと読めるというのは 非常にうれしい。
_ F#というよりはWindows APIの話が多いような気もするが進めている。
_ ノートPCはスタンドに立てかけておいて、その画面はちょっと見づらくても問題ない、 あまり使わないアプリを表示させている。で、メインは外付けのモニタをHDMIでつなげている。 それはそれでいいんだが、外付けのモニタを外すと、それまで外付けのモニタに表示させていた アプリはノートPC側に引っ越してくる。それもそれでいい、というか、そうでないと 表示できる範囲の外側にいてかえって不便なので、その方がよい。
_ よいのだが、さて会議とか出先から戻ってきて再度外付けモニタをつなげた後、 ノートPC側のウインドウを1つ1つ移動しなければいけない。これがなかなか億劫で、 数日に1回くらいならまあ我慢しないこともないが、日に数回というような頻度だと さすがに嫌になるし、トラックボールを駆使している私の指がとても辛い。 そしてなにより、そういう手間を考えて本当は別の場所にノートPCを持ってゆきたいのに なしで済ませようとする…というノートPCの用途として本末転倒な使いかたになってしまっている 面も否定しがたい。
_ まあ移動する前の位置を覚えておいてそこに戻せばいい…ので、そういうツールがないもんかと 思ったのだが、探しかたが悪いのか見付からなかった。のでF#の練習がてら組んでいる。
_ 最近はまったく触っていないが、考えてみたら仮想デスクトップと組み合わせることが できたらどうだろう。メインとサブのモニタそれぞれが、仮想デスクトップのどこかの1面ずつを 表示しているようなイメージ。これなら、モニタが1つになってしまったときはそのまま 仮想デスクトップを切り替えればよい、ということになる。
_ 私はもともとそんなに仮想デスクトップを使いこなせていたわけではないが、 少なくとも私が知る限りモニタごとに表示するデスクトップを変えることができるという 発想で作られたものは知らない。拡張された画面全体で1つのデスクトップ、であるのが 普通だろう…
_ Windows10標準の仮想デスクトップは、ディスプレイごとにデスクトップを作る、というような ことになっているようだ。これは私が望む状態とはちょっと違う… しかしまあ ディスプレイがぜんぶ同じ表示サイズを持っているわけではないのだから仕方ないのかもしれない。
_ GetWindowLong でスタイルとってきて絞りこんだり、 GetWindow でGW_OWNERがとれるかどうかで絞りこんだり、などなどをした。 そして GetWindowRect は最小化するととれないとか、 GetWindowPlacement でとれるけどそれはGetWindowRectでとれる座標とは 基準が異なるとか、いろいろ経験した。 Obtaining a window's size and position while it is minimized | The Old New Thing などを見た。
_ で、save/loadなどを実装してみた。試してみると…なんかVisual Studioの画面が うまく移動してくれないときがある程度であとはとてもよい感じ。外付けモニタを外す前にsaveして、 元に戻してからloadすれば、まあだいたい移動してくれる。いろいろ改善の 余地はあるだろうが都度いじってゆけばよいだろう
_ でF#の方だが、引数がひとつもない関数をletするつもりで () を忘れて呼ぶ前に実行されちゃったり、 Troubleshooting F#のやつをだいたい経験しているような気がする…
_ ( と ) の扱いに慣れない。使いかたが分からないとかつけ忘れるといったわけではなく、 この ( 〜 ) はいったいどういう意味で使われているのか？ というのが瞬時に理解できないことが多い。 何度も書いているように目が慣れていないだけかもしれないが、 tupleやunitで ( ) を使うのは今の私には混乱の元にしか見えない… あと項目の区切りをセミコロンでじゃなくてカンマでやってしまうやつも何度か経験した。 エラーメッセージの指す意味を理解するまでに数分を要したが、これはじきに慣れるだろう
_ 引数が足りない状態で関数を呼んだときの、fsiの挙動が、スクリプト的に使うときに 混乱の元になる… という話題もある。 理解はできるが、呼ばれていないだけ、という状況は気付かないと厄介だ。
_ あとionideを入れていたつもりで入れていなかった (入れていたのは家のPCだった) ということで なんかVSCode不便だなーと思ってしまったが、入れたらいろいろ便利になった。
_ まだ文法的に戸惑うことはあるものの、F#はけっこうさっさと慣れることができそうで、 最近面白くないことが多いのでもうC#で書かなきゃいけない場面でもF#使ってやろうか という程度に心が荒んでいるので、もっとF#を使う機会を公私で増やしてゆきたいと思う。 プライベートではまずZHTのプロセッサの刷新だろうか。 なお今だから明かすことができる話としてocamlは環境構築で挫折して放置している。 XML Light というやつを使いたかったのだが、そのimportが成功しないまま… なので 実質何もしていないに等しい。F#を達者に操れるようになれば、再度入門できるかもしれない。
_ 最近.NET Frameworkのソースを読む機会が増えており、 随所でこれ (System.Diagnostics.Contracts) を使っているのが目についた。 ContractってあのContractだよね… とドキュメントを見てみたらあのContractだった。 Invariantはどうやって検出しているんだ？ … とドキュメントを読み進めたところ、 ステップ実行的に都度調べているというわけではなさそうだ。
_ あちこちで使っているといっても、パラメータチェックや後始末のチェックで使っているようで、 なんかリリースビルドでも残るAssert的な使いかたがほとんどのような気がする。 一箇所にまとめて書きやすかったり、あとから集めてドキュメント化する場合などには 便利なのかもしれない。
_ TypeCには信号線が24本あるという記述があって、馬鹿を言ってはいけないUSBといったら 信号線4本だろう、と思ってしまったくらいUSB Type-Cのなんたるかを まったく理解していなかったので少し勉強した。 こりゃー分かりやすくていいなあ、というサイトがあって、ここにリンク貼っておこうと 思いながら他のサイトも見てみたら同じような詳細な説明があって、わりとあちこちで まとめられているらしい。コピペというわけではなさそうなので、孫引きなのかもしれんが…
_ この豊富な信号線をUSB以外の信号を流すために利用するのがAlt Modeというものらしい。 だからUSB Type-Cのドック的なものでHDMIやDisplayPortが使えるのね。 PDというのは電源供給らしい。
_ 仕事で使っているノートはというと、Type-Cの端子はあるがこのAlt Modeというやつで DisplayPortやHDMIを出せるのかというと、どうやらできないようだ。 仕様のところにはPDという記載しかない。記載がないだけで、実はできる…のかもしれないが、 じゃあそのへんに転がっているドックで試してみるか〜 と思っても転がっていないので 試すことができない。
_ RasPiいじるためにHDMI接続のモバイルディスプレイを所有している。 で、傍らにこのディスプレイを置いてみると、こんなふうに手元に表示できる デバイスがもう1つあればノートPCライフもちょっと変わるかもしれない… という気がしてきた。 しかし今のノートPCはRGB/HDMIは排他利用っぽい (物理的に両方刺すことができない距離になっている) し、 USB Type-C で外に出すのもむりっぽい…？ ので、その方向はむずかしそう
_ 一方でAndroidのタブレットがあったらいいなあと思っていたタイミングで (Lavie Tab W を使うようにしたので今はその気持は蒸発している) この手のモバイルディスプレイにうっかりAndroidも入っていますみたいなものがないかな？ と調べてみたら、もちろんそんなものはなかったけど (そういえばshinhさんが プロジェクタを内蔵しているAndroidタブレットに関心を持たれていたエピソードを 少し思い出したくらい)、Androidタブレットをモバイルディスプレイのかわりに使うソフト というのはいくつか紹介されていた。実現方式を考えるとさすがに会社のPCに入れるのは むりだけど…
_ Office365に移行してメールもOutlookになってしばらくたっている。 とくにすばらしいものだとは思わないが最近はメールの重要性も少し下がってきているような 気がするのであまり気にしていない…
_ そんな重要性が低下したメールについて、過去に関係したけど今は離れている 案件のメールなんかは、読んだところで反応できるわけではないし、反応できない 前提で読むと不快になることも多いので、受信したそばから既読にして放置している。 Webのインターフェースだとフォルダのところで右クリックして 「すべてを既読にする」を選べばよい。
_ で、そのすぐ上の項目は「フォルダを空にする」なので、こんな物騒なメニューを なんで近くに置くのか… と思ったりしつつ気をつけていた。とはいえ 実際に指示が反映されるまでのプロセスが両者には違いが…あったので、 つまり既読にする場合は選んだ瞬間に動作が始まるけど、 フォルダを空にする場合は確認メッセージが出る、というようになっていた。 で、最近になって既読にする場合にも確認メッセージが出るようになった。 もうオチが見えてしまったようなもんだが、 流れるように確認メッセージを見ずにOKOKとやるように習慣づいてしまい、 そしてついに今日やってしまった。
_ といってもいきなり全部消えるわけではないので、「削除済みアイテム」から 「元に戻す」を選べばいいだけの話なのだが… なにしろ数が多いし ブラウザはどんどん重くなるし操作している最中に画面の更新が走って選んだものが 選んでないことになっていたりもするし、トラックボールを操る私の指の痛みは どんどん悪化してゆく。最終的にはまだ「削除済みアイテム」が 残っているはずなのに「このフォルダは空です」という表示になってしまった。 実際には上の方で処理中のリングがぐるぐるまわっているので消えているわけでは なさそうなんだが、いずれにしてもPCの向こうにある世界で何が起きているかが 分かるはずもなく、そのリングもかれこれ3時間くらいまわりっぱなしなので、 どうにもならん
_ 今週は酒も飲まず無茶な食べかたもせず、 睡眠時間もけっこうとっているつもりなんだがどうも体調が優れない。 今朝も起きるのにかなり苦労した。
_ nugetとかでコンポーネントをとってきて使おうとするとこいつは.NET Standardが いくついくつを想定しているからお前のところでは動かないかもしれないぜといったことを 言われることがあり、そんなこと言われてもじゃあどうすればいいのよ…という状態だったので .NET Frameworkばかりを使っていれば済むという時代ではなくなっていることを痛感している。 少なくとも.NETというエコシステムに関わりつづけるのであれば.NET Coreは クロスプラットフォームだから当面は仕事では関係ないでしょ (^^) みたいな落ち着きかたを しているわけにはいかないということでもある。ので、表題のサイトを読んだりして 少し勉強した。 .NET Standard - Demystifying .NET Core and .NET Standard | Microsoft Docs というblogも読んだ。
_ .NET Frameworkは4.8が最終版になるのか。となると .NET Standard 2.1 以降に対応した.NET Frameworkはもう出ないということなのかな。 仕事で使っている間はセキュリティパッチなんかが出なくなったらきついけど、 別に最新の機能を追いかける必要はそんなにないわけだし、OSに最初から入ってくるものが どうなるのか？ みたいな話の方が重要だったりもするが、そういう前提を崩さない範囲で できる限り新しいものに合わせてゆきたいというのが人情というやつだろう。 新しいものが常によいものだという意識があるわけではないが、 古いままだと自分の意思とは離れたところで急に使えなくなる日が来る、かもしれない という警戒心が抜けない。といいつつVC++6.0は未だに手放せないというのは おかしな話のような気もするが… 別に好んで使っているわけではない
_ Introducing .NET 5 | .NET Blog。 .NET Core is the Future of .NET | .NET Blog。 次は5らしい。O'Reilly Learningにアクセスできるようになったおかげで .NET系の書籍がたくさん読めるようになったのでこのあたりをきちんと読んでおくべきだろう。 充実しているし、ちょっと目を通した限りでは異様に質が高いものが揃っている。 別に.NETの世界が居心地がよいわけではないが、意識するしないに関わらず公私で 触れているわけなので、もっと取り組んでもよいと思う。 今となっては、少なくともJavaやJDKの世界よりも私にとっては居心地のよい世界になっているわけだし…
_ MemoryStreamの話のつづき。 (注: ここで書いてある試行錯誤もぜんぶ勘違いなので注意) じゃあ他のMemoryStream的なものも試してみるか〜 と、いろいろ試してみたところ、 どれもうまくない。
_ まずPooledStreamと FastStream。 これらはArrayPoolを使ったものらしい。 どちらもLengthが141172280で止まっている。その状態でWriteByteとかをすると サイズは増えるものの、そもそも400MBを超えるデータを読んでいるはずなのに 途中で止まっていることには違いない。
_ 続いてMicrosoft.IO.RecyclableMemoryStream。 これはMemoryStreamのサブクラスになっているものの、アロケータにあたる部分である Managerが外出しにできているのでひょっとしたら… と試してみたところ、 こちらもLengthが141172280で、Capacityが141295616で止まっていた。 A replacement for MemoryStream - CodeProjectにある MemoryTributary というやつも試してみたが、これも同じく141172280で止まっている。
_ さすがにここまで来ると何か別の原因にひっぱられている気がしてくるが… しかしStream.CopyToの実装なんて誰が書いてもこんな感じだろうというものだし、 中で使っているStream.Write は void なので全部書けたか書けなければ例外か、 ということにしかならず、途中までしか書けていないという状況がよくわからん
_ なんだ、.NETではたかが400MBのデータをメモリに置いてStream的に使うという 簡単な仕事すらできんのか？ … と、ここまで書いてようやく気付いたが、 DeflateStream.Read が途中で止まってしまっている可能性を考えていなかった。 間抜けだ。明日もう1回見直してみるか〜
_ なんと、今日は祝日だった。
_ ということに一昨日の夜気付いて、じゃあ日曜は休むかーと思った。
_ 試しにターゲットのファイルをzipからとりだした状態でFileStream→MemoryStreamにCopyToしてみた。 とくに問題なくできる… ということはMemoryStreamは無罪だったということではないか。 ごめんよ
_ ということはDeflateStreamが全部読み終わってないのに終わっちゃってるということかなあ？ … そもそも ZipArchiveEntry の Length や CompressedLength が実際の値と合っていない。 Length は、141172280 となっており、そのためそこまでしかデータがとれていないようだ。 CompressedLengthは、83876603 となっており、 エクスプローラで見る限りでは実際の圧縮後のサイズは 262,645 KB なのでぜんぜん少ない。 なにが起きているんだ？
_ ………？？？ エクスプローラで見ていたファイルと実際に展開しようとしているファイルが 違っていた。違っているものを比べたらそりゃ合っているわけがない。似たようなファイル名が 大量にあるので勘違いしやすいとはいえ情けないミスだった。
_ そしてつまり何が悪かったのかというと、CopyToした後MemoryStreamのPositionを0に 戻していないだけだった… CopyToした後にMemoryStreamはストリームの末尾にいるので、その状態で中身を 解析しようとしてデータないんですけど (^^) と怒られていたようだ。 伸長が途中で止まっていたと思いこんでしまったのはいろいろな不幸が重なったとはいえ情けない…
_ ようやくPcapngFile でフレームを1つずつばらすことができるようになったので、 それをPacketDotNet で解析できるようになった。
_ 今の段階では、ディレクトリやzipを舐めてpcapngとってきて、それを1つ1つ解析する、 というだけなので、ここまでの作りかたは別にどんな言語でやっても大差ないと思う。 で、ここから解析を行ってゆくと、どうしても状態を持ってまわらないといけなくなる。 外部のモジュールを呼んだり、状態を外出しにする… というのは、たとえば Erlangなら applyで外部の M:F/A を呼ぶようにしたり、gen_serverなんかを使って 状態を持っていてもらったり… というような感じになると思う。 C#だと、クラス作って処理の経過で持っていたい状態はインスタンスの中で保持する… なんてことをするか、簡単なものならdelegateでコールバックさせるとか、そんな感じだろうか？ Pythonでもだいたい似たようなアプローチになると思う。
_ F#だとどういうのがいいのかな。奥の奥までなんかデータをひきわたしたり、 コールバックをひきわたしたりというのはやりたいことではない。 シーケンスにして、パケット1つが見つかるたびにyield… というのは、まず思いついたものだ。 Pythonでも似たようなことをすることがあるが… シーケンスに仕立てあげるのは 特に大きな改造というわけでもなさそう。なんとなく、シーケンスを意識して 作っておけばあとから並列化するときにも有利な気がするがどうだろう
_ F#におけるよいデザインというのは、実際にF#で書かれているアプリのソースを読んで 学ぶなどがいいのだろうと思う。適当なものはないかな… 今のところ 普段から触っていてF#を使っているものというと、 W10Wheel.NETと FsCheckくらいしかない。 他にもWebアプリフレームワークなんかを眺めてみる限りでは、 適材適所というべきか、Objectでまとめておいて、中をfunctionalに書いている…という 印象を抱く。ただ、とくに外部から使われるものについてはF#専用にするつもりがないから そうしている、という可能性もあるのでむずかしいなー
_ 微妙に頭痛が続く。頭痛自体はほぼ毎日あるので日頃から続いているとも言えるが、 そういう普段の頭痛は強弱があって、痛みがあまり強くない時間帯もそれなりにあるし、 寝て起きればおさまっているということも多いのに対してここのところの頭痛は 寝ても起きても…という感じだ。といって仕事にならんほど痛いというわけでもない
_ は、やっている時間がとれなかった。
_ プログラムの大きな構造をどうするといいんだろう？というのは試行錯誤しながら 改善してゆけばよい気がするし、それと並行で、よいプログラムのコードから学んだり 本読んだりしてゆけばよい気もする。とはいえ、関数型言語だと通常どうやって プログラムを構成するんだろう？という興味も一方ではある。 本や小さなサンプルを読んでも、局所的な構造は分かるけどプログラム全体をどう構成するのかは 分からん。Erlangでは昨日書いた通りで、一番触ったLispはEmacs Lispで、あれは globalにとれるデータがたくさんあるのであまり構造がどうのこうのということで 悩むことはなかったように思う。
_ 純粋な…と書いてしまうと別の意味になってしまうが、マルチパラダイムではない ラジカルな関数型言語でプログラムを書いてみる…というのも取り組んでみたい内容だ。 といっても、じゃあ何ならいいのよ、というのがあまりアイディアがない状態だが…
_ 1/15は妻の誕生日だったので1回休みにして料理つくったりした。 いろいろ思い通りに行かなかったし粗相も多かったがどうにかこなすことができた。
_ 特定非営利活動法人 失敗学会 にひきつがれた らしい。 気付かなかった。
_ このデータベースはもともと科学技術振興機構(JST)が展開していたものだが、 「事業仕分け」の影響によりサービスが終了した、というのが定説になっている。 少なくとも私はそう理解していた… のだけど、実際のところどうなんだろう？
_ 内閣府の行政刷新 - 内閣府から当時の様子を読むことができる。 科学技術振興機構は第一回、第二回にそれぞれ出てきており、 第二回の B-10 がそれにあたるんじゃないのという話になっているようだ。 結果。 「失敗知識データベース」と名指しされているわけではないので、この中のどの項番が 該当するのか…はよくわからない。議事録が公開されているわけでもないし…
_ ただ事業仕分けについては「ライブ中継」をいくつかのサービスがやっていて、 そのときの様子がまだ記録として残っているところがあるようだ。それを見れば もうちょっと分かることもあるかもしれないが… あんな、ぐろ動画をわざわざ見たくないなあ… 巻き込まれた組織や人々には気の毒だが
_ 別にLinusがZFSのことをどう思おうがどうでもいいというか、 Linuxに取り込まれることがOpenZFSにとってどの程度重要なのかがよくわかっていないのだけど、 本当にZFSのことを分かってて書いているのだろうか？ Btrfsと間違っているんじゃないの？(ひどい) と思ってしまったのだけど、 その後のフォローを読んで、 まあ言いたいことは分からんこともないというか、 でもBuzzwordはないだろうやっぱりLinus嫌いだわ、という感想になった。 なに言ってんのこいつ的な論調は Linus Torvalds says “Don’t use ZFS”―but doesn’t seem to understand it | Ars Technicaにも上がっていた。
_ 1. メルカリの品物を落札してPaidyの支払いを選択する→2. 品物が届く →3. 実はその商品は出品者が量販店などでPaidyで購入したものであった → 4. 3の請求が落札者に来る → 5. 落札者は二重に支払いをすることになる、 という流れらしい。 という話は数日前に出ていて、さっぱり理解できなかったのはなぜ3の請求が 落札者に来るの？ という点だ。購入者である出品者に請求が行かないのはなぜ？ あちこちの記述を見てみると、「出品者が請求を無視すると購入者である落札者に請求が飛ぶ」とか 「落札者に請求が飛ぶように仕向ける」みたいな、具体性にも信憑性にも乏しい記述が多い。 詐欺発生の「Paidy」、提供元が対策 「悪用の恐れある」取引を制限・停止 - ITmedia NEWS (購入者が商品を受け取ると、通常通りメルカリ経由で出品者に代金を支払う。しかし出品者がPaidyからの請求を無視し、商品の送付先である購入者に請求書が届くよう仕向ける。) など。 どっちにしたって購入者＝出品者が債務者なんだから、落札者は関係ないから放っておけばいいじゃないの、と思った。
_ いろいろな記事を読んでみて、どうもこのPaidyというサービスの利用を開始するにあたり 必要な情報というのが、携帯電話とメールアドレスだけなので、 出品者は落札者から得たそれらの情報を元に落札者としてサービス申し込みを行い、 お買い物をするという流れだったようだ。 本人確認もなしにサービスを使うことができてしまうのであればそういう 手段も使えてしまうということか…それにしても落札者はすでにPaidyを使っているわけだから 複数のサービス登録を許しているということになりそうなもんだが…
_ 後払い式の決済にしては規約も異様に短かい。 下の方にある「仕組み」を眺めたり、規約の中身を読んだりした限りでは、 どうやってこの3の請求と、その元になる契約を無効にできるのか、という答えが見付からない。 そして落札者はこの契約の流れにまったく気付くことができないのか？ という点も。 ともあれ、 クレジットカードよりも審査のプロセスを簡略化しているなら、せめてクレジットカードの 世界がどういう問題と戦ってきたのかくらい考えないもんなのだろうか。 悪意のある人であればより簡単に詐欺行為ができてしまうようなものを作り上げているという 自覚があるんだろうか… この手の新しい革新的な決済手段的な触れ込みのやつは、 気持が暗くなるようなニュースばかりをもたらしてくれている気がしてならん…
_ …… それにしてもこれ本当に落札者は気付けないもんなのだろうか？ 量販店から荷物が届いた、という違和感に頼るしかないのか？ サービスの説明を見る限りでは決済時に「本人確認」をしているようだ。 この詐欺行為には、落札者が出品者に支払うときにもPaidyを使っている、 というのが、必須なのかそうでもないのか、がよく見えない。が、 どうも、出品者への支払いのつもりで、お買い物に対してパスコード入力を してしまった。という話なのだろうか？ それにしても、携帯電話の番号は本物なのだから、 これを「本人確認」とされてしまうとリンゴが落ちる様子を見て即座に運動方程式を導き出すような 洞察力を求めている気がする
_ …… どうもパスコードを入力せずに無視していても督促が来るだけだみたいな記述をしている 人もいるようで、いよいよわからん。同じ手法での詐欺はもうできないらしいし、 もうちょっときちんと解説しているサイトはないもんか
_ なるほど… これらの数字を見てピンと来なきゃいけない日がもうそこまで来ているのかもしれない
_ なんだか常に眠いような…単に目が疲れているだけのような… よくわからないもやもやがある
_ そして先週末の爪切りのやりかたがうまくなかったらしく 左手薬指が巻き爪になってしまったようだ。今朝意を決して陥入しているところを少し 切ってみたところ多少楽になったものの、まだ痛い。見掛け上は痛そうに見えないのに キータイプをする気にもならない痛みという意味では関節炎もそれに近いかもしれない。
_ そういえばこのAndroidアプリでTalkbackが使えたらいいなあと思うんだけど、どうも うまくない。見えている部分を読み上げるというよりは、 ページの単位でしか読んでくれないようだ。これだとさすがに辛い。もうちょっと アプリは頑張ってもらいたいところだが…
_ 前半は要領よくF#のことを説明してくれており、後半は いくつかのテーマでアプリを作っている。アプリの方は、なぜその題材なのだろう？という 感じを抱かせる部分もあるものの、自分のやりたいことに近ければ役に立ちそうだとは思った。
_ もともとこの本を読みたいとなった時に O'Reillyのサービスのことを思い出したような感じなので読めてうれしい。 method〜interfaceあたりの説明は、 どういう意図でそういう仕様にしたのか、も含めて説明してくれているので なかなか他の本では読めないと思う。
_ 今日もセンター試験か… センター試験の日程が2日間であることすらすでに忘れていた。 そしてセンター試験は今回が最終回で、来年からは別の名称になるらしい。
_ NSAが見つけて知らせてきた、という脆弱性の話。どうもNSAの言っていることと このページに書いてある内容が合っていないような気がする… よくあることなのかもしれないが、 Microsoftのサイトで書いている内容は問題を小さめに扱っている？
_ それにしてもNSAがねえ… ということでおどろいている。 暗号をかけるのがRSA、バックドアを作るのがNSA、という大喜利的なねたがあるが (さっき作った) どういう風の吹きまわしなんだろう。散々利用しつくしてもういいと思ったとか、 あまりにも問題がでかすぎて国内のPCやサーバが標的になったら大変なので公表に踏み切ったとか、 そういう勘繰りをしたくなってしまうのだった。真実は分からん
_ まずHDD不調でこわれていたUbuntu+Rancher環境を 復活した。 Ubuntu 18.04 Root on ZFSが、また改良されていた。 たとえばディスクのデバイスをあらかじめ変数に入れとくとか。これにより 途中のコマンドをほぼコピペでできるようになた。 あとDisplayPortがつながるモニタが遊んでいたので、Ubuntuのデスクトップを インストールした。これでO'Reilly Leaningくらいなら読めるようになるので都合がよい
_ また、サブモニタあったらいいな欲をごまかすために、Raspi+モバイルモニタ環境と、 ArrowsTabのそれぞれにSynergyを入れて、ノートPCにつなげてるキーボードと トラックボールから操作できるようにした。↑のUbuntu環境も同様にsynergycを入れたので、 ノートPCとサブディスプレイの他に、タブレットとUbuntuPCとRaspiがそれぞれ手近なところで 動いており、同じキーボードとトラックボールから操作できるようになった。 もっと早くやっておけばよかった
_ 2019年中に着手できなかったKotlinについて取り組み始めることにした。 今日は教材を探したりする程度で、実際の取り組みは明日以降になると思う。
_ Koansはわりと実践的な練習問題になっているような気がする。 O'Reilly Leaningで読める本は、Android向けの本が少ないし、あっても古いようだ。 なので別の方法でやらないとだめかな。 Udacityのコースも、 無料の方は言語の入門という感じで、これならPlaygroundで十分な感じ。
_ 5時過ぎに目が覚めてしまった。そのままフトンでじっとしていた結果、 いつも起きる時刻の20分前くらいからウトウトしはじめたようで、結果として眠い。 いい加減真剣に生活の見直しが必要そうだ。睡眠時間は決して短かくないのに、 日々しんどくなっているように思う。
_ 先日2.5Lの湯たんぽを買った。2.5Lはちょっとでかすぎた。 いったんフトンに入れれば半日くらい暖かいままでよいのだけど、 2.5Lのお湯を準備するのが大変。 fashyのようなフレキシブルなやつならよかったんだが、今回買ったのは ポリエチレンのやつなので、満タンにしておかないと使えない。
_ その後ダイソーで600mlの湯たんぽを発見したのでそちらを使っている。 これでも8時間くらいはそこそこ暖かいままなので悪くない。とくにフトンに入ってすぐの、 冷えきった足が温まるまでの時間がかなり短くなってありがたい。といっても30分くらい かかってしまうんだが…
_ そして何も考えずに入れっぱなしにしておくとけっこう暑くなるようで、 気付くとフトンを蹴っていることが多い。むずかしいもんだ
_ 久しぶりに時間をみつけて触る。触っていない間も本や記事などを読んで イメージトレーニングをしていたので、ひとまずキャプチャの分析の話のつづきで、 sequenceを中心にした処理に変えてみた。変えている最中にいろいろ不要なところが でてきて、それを削ってすっきりしたり、いろいろ無理のない作りになったようには思う。
_ 数日のブランクがあるので必要のないendを書きがちだった。 あと、パターンマッチの最中に長いものを書くことに躊躇を覚える。 Erlangでは何とも思わなかったので、オフサイドルールに対する 警戒心がそうさせるのかもしれない。そうでもないのかもしれない。
_ 今のところKotlinはAndroid以外の用途で使うつもりはない。 ただKotlin/Nativeとか面白そうな枠組みがあるので今後気が変わるかもしれない。 とはいえF#やGoのかわりになる日が来るかどうか… という感じもする。 .NETの世界にもKotlin/Native的な仕組みはあるようだし
_ Build Your First Android App in Kotlinという tutorialがあったのでそれで試してみようと思ったのだが、 Android Studio 3.6以上を要求しているようだ。私が最新版だと思って落としてきたのは 3.5.3なので、それよりも新しいバージョンを求めてくるというのはなかなか チャレンジングだ。 Stableというチャンネルにいるからだろうな… 3.6系は、RC1が出ている。 プレビュー版とそうでない版は共存できるらしいので、そっちも入れてみた。
_ DDMSはもう使わないのかな。Android Studio にはDevice File Explorerというのがあった。 どうも廃止になったらしい。 まあDalvikなんて名前が残っているようなものをいつまで使うんだという気はしていた
_ Udacityに、Android+Kotlinの無料コースがあった。 必要に応じてやってみるか…
_ 3.6RC1を入れて、↑のtutorialをひと通りやってみた。 layoutのデザイナがよくできているし、 navigationの編集がグラフィカルにできて、うけわたしするBundleについても 自動的に？ ラッパーを作ってくれているようで、とても楽ちんだった。
_ IDEAはあんまり使ったことないのでキーバインドがいまひとつ慣れない。 「実行」が状況によってSHIFT+F10だったりCTRL+F10だったりするのはなんとかならんのかな。 エディタのフォントサイズをでかくすると、 ConsoleとかLogcatもそれに合わせてでかくなってしまうようで、これもこれで困っている。 今のところはそれくらいかな？
_ あとはやっぱりメソッドの先頭が小文字というのが目に慣れない感じでつらい。 つらいだけでなく打ち間違えることも多く、その場合はヒントとして出てこないようだ。 Visual Studioだとかなり保守的に候補を出してきてくれるので、大文字小文字を 間違ったくらいではどうということはないのだが…
_ いずれにしてもtutorialをひと通り終えることができてよかった。 私は、ちょうどFragmentというのが導入されつつある頃に、Fragmentを使わないで プログラムを書いていた方なので、今になって再びやることになるとは… という不思議な 感覚がある。当時はなんかとっちらかっているような印象を抱いてしまっていた。 理解する意思が乏しかっただけなのかもしれんが、単にややこしくなっているだけ という印象が勝ってしまい、タブレットも持っていなかったしあまり積極的にやりたい 感じではなかった。もっと言うと、いずれひっこめるんじゃないかというあまり根拠のない 予想をしていたりも。今目の前にあるFragmentが当時とどのくらい同じでどのくらい違うのかは、 当時のことを理解していない私には分からんが…
_ Android中心で取り組んでゆくことになるので、その際にKotlinのスキル不足が 足を引っ張らないように、空いた時間でKoansとかをやっておこうかなと思う。
_ 冬場は寒くて走る気力がなかなか出ないのと、先日走ったときに息切れがひどく こりゃー走るコンディションになるまで走るのは減らしたほうがいいなと思い知った。ので 歩く量を増やすことにした。米沢にいた頃は歩くのは大好きだったが、 街中を歩くのはそんなに楽しくない… が、まあ連日同じ景色を見るというのも アトラクションのひとつだと割り切ることにする。
_ で仕事帰りに歩いたんだが… そこそこの重さの手提げを持ちながら、脱いだコートを 持ちながら、革靴で歩くのはわりとしんどいようだ。靴や鞄の整備も必要かもしれない。 あと、家までおよそ80分かかり、これが微妙に飽きる。 60分を超えたあたりから、疲労とは別の飽きるという感覚が出てくる。 もっともこれは地理的な要因もあるのかもしれないが… 隅田川を超えてからの 2〜30分が長く感じるというやつ。1時間ちょうどか、少し下回るくらいの距離となると、 水天宮前くらいまで移動すればよいのかもしれんが、2〜3駅の移動のために電車に乗るというのは なんというか間抜けに思える。
_ とくに冬場はワセリンが大活躍で、塗りたい箇所をあらかじめ湿らせておいて、 濡れた手にワセリン載せて温めてから伸ばす… という感じでかなり良好な保湿性能を発揮している。 ただ成功率が必ずしも高くない…というのは言いすぎかもしれんが、100%というわけではなく、 たまに、一部が塗れてないとか、 逆に衣服に移ってしまいそうなくらい残ってしまうといった塗りむらが多い。
_ なのでベビーオイルで代行できないか試している。久しぶりに使ったベビーオイルは、 こんなにそのまんま油みたいな触感だったっけ、とちょっと驚いた。そして気付いたらその べたべたはなくなって、さらさらになっている。どういう仕組みなのかはよくわからないが、 その特性によるものなのか保湿能力はワセリンにはずいぶん劣るような気がする。 ただベビーオイルを塗ってすぐのところはステロイドなどの軟膏や、ワセリンなどが 伸びやすいので、不足しているところはワセリンで補えばいいかーという気がしている。 あるいは単に量が少ないだけなのかもしれない。休みの日に多めにすることを試してみるか…
_ Koansを昨晩も続けていた。しかしこれKoansという名前の通りある程度中身を 分かっている人間が理解度テスト的に使うのが本来の形なんだろう。 初心者向けの心配り、たとえばこのKoanはこのドキュメント読みながらやってね、というような コメントは入っているものの、そこに書いていないものを普通に要求されるので 対象のことをほとんど理解できていない状態で取り組むのはきつい。
_ 各所のドキュメントで見掛けるのがAndroid Jetpack なる謎の用語だ。 これか。KTXという用語も よく見掛けたが、Kotlin向けの拡張 らしい。 KotlinもAndroid Studioも、Androidも、このJetpackというやつも、 どれも変化が激しそうなので、ちびちびとやっているとなかなか身につかないだろう。 一定期間は集中したほうがよさそうだ。でもF#も触りたいんだよなー Erlangを なかなか触れない寂しさを紛らせてくれるのはF#しかないようだ。
_ ひとまず今月一杯は軸足をKotlinに置くことにしよう。 Kotlinが6、F#が3、Goが1という感じだろうか。本当はGoのウエイトをもっと増やさないと いけないんだが、馴染の浅い言語を2つ同時にやるのはけっこうしんどい。 F#は馴染めないというほどではないので大丈夫だ
_ あと、AndroidやKotlinの周辺のドキュメントは、和訳されたものでも 比較的読めるものが多いと感じる。Microsoftの和訳ドキュメントは、 きちんと翻訳されたもの以外は読めたものではないので、今のところは Microsoftより好印象に感じる。とはいえMicrosoftのドキュメントの蓄積は膨大だし、 単に私がAndroidやKotlinの露出度が高い部分しかまだ見ていないから そう思えるだけなのかもしれない。リンク辿った先が英語だった、といったケースも けっこうあるし… それでもMicrosoftの機械翻訳通しただけみたいなページよりは 好ましいと思わざるを得ない。
_ そういえばLeetCodeはKotlinには対応していたのだった。 最初期のGoいじりのときも多少は役に立ったし、Goで書いていても楽しくなかった LeetCodeも、Kotlinなら少し様子が変わるかもしれない。 F#は、もう実戦投入できているので、訓練のためにやることはないかな〜という気がする。
_ さっそくLeetCodeの1問目 (Two Sums) をやる。 ループまわすのは別に難しい話ではないのでいっぺんそれでsubmitしてみた。 Goの5倍遅く(48msec→216msec)メモリは10倍以上喰っている(3MB→43.6MB)。 それはそれとして、List comprehensions的な処理ができれば かなりコード量は短かくなるはずだよなあ… と試してみたところ、 巨大なintArrayに対するテストでタイムアウトになってしまった。
_ Erlangのときも同じような悩みを抱いたことがあるのだが、fold とか filter とかで 途中で処理を打ち切る、という制御構造が欲しい。けど適当なのが見つからないので結局 手づくりすることになる。…が、凝ったことをしようとすると結局元々のループ処理と 大差がないような気もしてくる。汎用性のある構造を作ることができればよいのだけど、 まだコーディング能力がそれに追い付いていない。
_ そうそうAndroid StudioやIntelliJ IDEAにはKotlinのREPLがあるようだ。こりゃーべんりだ
_ これはすごい。電子化されることはないようなので、普通に買うか…？
_ 結局やる。シーケンスで貰えたやつをSeq.fold で順番に実行してゆく… というような構造にしてみたがどうだろう。状態を引き渡しつつループするというと すぐに思いつくのがこの形式になるが… 今のところすごくすっきり書けていてよい気がする。
_ F# では複数のデータをまとめてどうにかする構造が複数あって、 それらはだいたいメンバーを持てるのでどういうときにどれを使えばいいのかね？ という点で悩みを覚える。 Recordの章にあるDifferences Between Records and Classesとか、 Classの章にあるWhen to Use Classes, Unions, Records, and Structuresなんかを読んで 自分なりに理解した限りでは、基本はRecordとDiscrimination Unionを使っていって、 それでは限界があるときにStructやClassを使う…という形だろうか？ 限界というのは、たとえばC#でも使いたいとか、 Polymorphicなやつをやりたいとか…
_ Recordは、作る際に持っている値たちを全部指定しないといけないみたいだ。 Goのstructみたいにゼロクリアが強制されていれば楽なんだけど… なお↑のRecordの説明を読む限りでは、default recordを1つ用意しておいて、 初期値を変えたいときは with なんとか〜 で変更する、というやりかたを推奨しているようだ。 1回は全部指定しなきゃいけないことには変わりないが、それならそれでいいか〜
_ if で MemoryStream、 else で FileStream をそれぞれ返す、なんてことをしようとすると、 if と else で返す型が違うと怒られるので Streamにアップキャストしなきゃいけないようだ。 あるいは、戻りの型をきちんとStreamと指定すればいいかな… ？ と思い試してみたところ、 StreamとMemoryStream/FileStreamは型が違うと怒られる。そういうもんなのか
_ なお先日作成したウインドウの位置を保存/復帰するスクリプトは極めて便利に使っている。 席を離れる前にsaveして、戻ってきたらloadする、だけで、だいたいのウインドウは元の 位置に戻ってくれるのでとてもありがたい。もちろん出先で新しく作ったウインドウは 戻ってくれないけど、それはさすがにしょうがないだろう。 保存されていないウインドウはとりあえず動かす、というような戦略も可能だが…
_ O'Reilly Leaningで読めるので、ちびちび読んでいる。 インタビューする人もされる人も有名で有能なひとたちばかりで、一人一人の インタビューがかなり長い。質問項目がある程度統一されているので、同じ内容について 三者三様の答えがあるのが面白いし、その答えになった理由をきちんと聞き出しているので 大変に充実している。
_ ただC++を擁護する意見はほぼまったくないのが興味深いというか笑えるというか… せいぜい、Bjarne Stroustrup に配慮が必要な立ち位置の人が本人を擁護するという程度で、 あとは積極的に憎んでいるか、近付かないようにしているか、やむなく使っている、といった 態度ばかりだ。これだけ有能な人達がC++に対してそういうつきあいかたしかしない、 というのは、やはり興味深いと思う。
_ これについてもCoders at Workでインタビューされている人が様々な意見を述べている。 私自身は以前書いた通りボトムアップ派だ。 理由も当時書いた通りテストがしやすいというのがある。ただ、 Coders at WorkでJoeがほとんど同じような回答をしていたので、意識してか無意識かは ともかく、それに影響されている気がする。 Coders at Workを最初に読んだのは、記録に残ってないから なんとも言えんが2013年当時にはもう読んでいたと思われるし…
_ ここのところ思うのは、トップダウンだと別にプログラム言語じゃなくてもいい範囲が けっこうあるんじゃないの？ ということだ。たまに、トップダウンのアプローチで プログラムを書くことがあり、その際は、おおまかな流れを記述するのは コメントに書いた日本語だったり疑似コード的なもので済ませることが多い。 そして、そういうトップダウン的な書き方をするのは、 すでに要求仕様やフローががきちんと記述されているものとかに限られるようだ。
_ ボトムアップのアプローチは他の人のコードを読むときも同様かもしれない。 何か目に見えるもの、たとえばメッセージとかを手がかりに関心がある部分を探して、 デバッガが使えるならそこで止めて、少しずつ呼び出し元に戻ってゆく…というやりかたが多い。 まず全体を把握してから…というようなアプローチはまずしない。
_ 書くときも、読むときも、ボトムアップではどうにも行き詰まることがあり、 そのときになって初めてトップダウン的なアプローチをすることになる。 やっている最中につまずいている部分をきちんと控えておいて、それらが解決することを 目指しつつ読んでゆき、最終的にはトップダウンとボトムアップが出会って全部つながる… みたいな感じだろうか。ボトムアップだと、とくに読むときはなかなか体系的な理解に 至らないので、時間を空けて再度ソースを読むよ際に同じようなことを何回もすることに なりがちかもしれない。繰り返していると少しずつ体系的な理解に至るというべきか… 一方で、トップダウンだと、その時どきの関心の範囲だけを考えると無駄な 読解が増えるけど、体系的な理解ができていればだんだんコストが下がってゆくのかもしれない。 どっちにしても苦手なのでうまくできない…ので、せめてできるのは、ボトムアップ的な アプローチで得た理解をその場限りで終わらせないような記録の残しかた・記憶のしかたを 工夫する、という程度になってしまう。
_ とりとめがないが、トップダウン的なコーディングができない理由として根本的なのは、 名前をつけるのが苦手だというのがあるようにも思う。小さなロジックであれば それにつく名前が適切かどうかはある程度判断可能だけど、「おおまかな流れ」に対して 名前をつけようとすると、なかなかむずかしく感じる。私がプログラムを書いている中で、 手が止まる瞬間というのは、慣れていない環境でのデザイン的な悩みを除けばほとんどが 「関数や変数の名前をつける」だ。
_ さて次はUdacityのやつやろうかしら… と思ったんだが、 Self Pacedとはいえ想定期間が2ヶ月程度と言われると躊躇する。 いろいろ探してみたところ、 Udacityの講義の元になっているのは書きもののTutorialのように見える。 Kotlin Bootcamp for Programmersと、 Android Kotlin Fundamentals。 こっちをやればいいかなーという気がしてきた。
_ 書きもののTutorialであればいろいろスピードアップする余地はあるが、 反面手が止まってしまったり、手を抜いてあまり身についていなかったりすることが あるかもしれない。一方この手の学習プラットフォームなら、 動画を中心に追いかけることになるので迷子になることはまずないだろう。 一方でスピードアップしたくてもできないという問題がある。
_ ひとまず1〜2日、書きものの方をやってみて、問題なさそうならそのままさっさと 終わらせてしまおうと思う。
_ Kotlin Bootcamp for Programmers からはじめる。 ……… そうかAndroidが絡まないKotlinの開発をAndroid Studioでやることはできないのか。 そりゃそうか。IDEAを入れる。
_ Kotlinでは関数は最後の引数でとる慣例があるらしい。 たしかにこういう書きかたができるのはメリットかもしれない。が、 パイプライン演算子みたいなものは実現できないように見える。この例みたいに foldとかfilterとかがメソッドであればあまり大きな問題ではないのかもしれない
_ IDEAではmutableな変数にはアンダーラインで装飾されるようだ。これは分かりやすい
_ Lesson 4 まで終わった。openしないとoverrideできないというのはよい気がするものの、 親クラスを作っている段階でoverrideされる可能性があるかの考慮をミスすると サブクラスが不便というのが問題になる場合は問題かもしれない。自分で書いたやつや 社内のものであれば、じゃあ見直すか…と簡単にできることもある (できないこともある) が、 そうでなければきびしいだろう。とはいえそのあたりの考慮ができていないものが overrideしても安全かどうかというとそうでもない気がするし、 そもそもC#だってvirtualつけてないとoverrideできずnewするほかないという 運用になっているわけだし、だいたいinterfaceを中心にしたプログラミングであれば このあたりは自然とそうなっているわけだし、それ以前にcompositionがやりやすい 環境になっているようなので、このあたりはうっかり問題を起こすことが減ったという 好意的な解釈でよいような気がする。
_ 向こう1日半はこのあたりの取り組みができないが、このボリューム感であれば週末までには Androidの方も含めて終わりそうな気がする。そこですかさずAndroidの開発ねたが出てくれば よいのだが、もうちょっと後になるかもしれない。Kotlinの勘を鈍らせないように
_ 今日は1回休み。いろいろ計画を事前にしていたんだが、9時過ぎに目が覚めたら 身体がとてもだるく活動することができなかった。 11時くらいまでフトンでうだうだして、再度寝て、気付いたら14時だった。 そしてだるさはほとんど改善しておらず、それに加えて頭痛まで…
_ 借りていた本を返さなければいけないこともありようやく活動を始めた。
_ Dr林のこころと脳の相談室の 精神科Q&Aで何ヶ月か前に掲載された 【3868】コンサータによって自己の連続性を失いつつあるは、 ここ何年かの中で屈指のエントリだと思う。 このQ&Aの中でDr林が紹介している本が表題のものだ。
_ マイケル・S・ガザニガは、 アメリカの心理学者らしい。 分離脳患者の研究を通して右脳左脳の特性や 相互のやりとりについていろいろな成果を出したひとらしい。 この本は、ガザニガが ギフォード講義で行った 講義を元に構成されたものらしい。そのせいもあってか、 対象をとりまく問題の難しさを、 様々な分野の理論や仮説を紹介しつつ描写してゆくという構成になっているので、 書籍として読んだときに少々とりとめのなさを感じる。 この本で幅広く紹介されている事柄について、興味を引かれた部分を、 出典などを元にさらに学んでゆく、というような読みかたになるのかな、と思う。
_ 「インタープリター」について説明している部分は、 私がよく書く「後付けの理屈」そのものだった。なぜそう考えたのかを 説明しようと試みるときに常に抱く感覚だ。比喩として使っていた「後付けの理屈」は 実際その通りだった、ということか〜
_ 原著はKindleで、和訳は単行本で読んだ。原著→和訳→和訳→ と読んできた。 原著は、今の私には少々きつかった。別に難しい英語を操っているというわけではなく、 臓器・器官などの用語が理解できなかったり、 実験の手順について記述しているところで途中で迷子になったり、ということが 多発した。KindleのWord Wiseも、たまに「Medical word」みたいな、 それは分かってるんだけど的な註釈しかしてくれないことがあって難儀した。 和訳を2回読んだので再度原著を読み直してみるつもりだ。
_ この本と、それを読むきっかけになったQ&Aと、Dr林のコメントは、 私が抱いていた疑問というか違和感に近いものを表現していると感じたわけだが、 私の疑問というのはもっと素朴なもので、 生まれか育ちか (この本では「nature or nurture」と表現されていた) とか、 決定論、といった話以前の疑問として、 人間というものが遺伝と環境のいずれかまたは両方でつくられているのであれば、 自分というのはつまりなんなのだ？ という感じのものだ。 あらかじめ決定したものであってもなくても、 遺伝であっても環境であっても、どっちにしても「自分の外」にあるように 見えてしまうので、つきつめてゆくと「自分の意思」なんてもんは なくなってしまうのではないのだろうか？
_ 自分の意思の存在を疑うことはないまま日常生活を送っているという 事実もあるわけで、この、自分の意思なんてものが果たして存在するのだろうか？ というようなラジカルな見解と、わりと不具合なく自分の意思で生活できている 事実のギャップというのがとても不思議に感じる。 私なりの結論というか、妥協点としては、 まずそんなことを言っていたら元も子もない、というのが1つ目だ。 何か問題行動があったときにその責任を本人の意思に求めることができないのであれば 社会が成立しないではないか、というような発想。 もう1つは、年齢を重ねるにつれ、だんだんと「自分の意思」というもののウエイトが 大きくならざるを得ないのではないか、という感じの、うまく説明できないが、 そういう発想だ。その自分の意思というやつがどこから生まれているのか、 という点にはあいかわらず答えられないわけだけど。
_ 意識は多数の分散したシステムである (定説) にも かかわらず統合された意識の実在を確信している状態をつくりあげているのは なぜか？ という、この本に書かれていた疑問 (意訳) は ここまでに書いた内容に近いのかもしれない。そこにはインタープリターが 大きな役割を占めているようで、つまり統合されているというのは そう見せられているに過ぎない、という話になる。 Q&Aで書かれていた「自己の連続性」というのもそれにあたるのだろうか。
_ 昨日も歩いて帰ってきた。歩いていると暑くなるので薄着で歩き始めて、 結果けっこう寒いので体調が悪いのはそのせいかもしれない。
_ そして50分超えたあたりで絶妙に飽きるのも通例通りだった。 でも昔の武士やら同心やらは、このくらいの距離を普通に通勤で 歩いていたんじゃないのか？ という思考になり、がんばって歩いた。 当時の人達がPodcastを聞きながら通勤していたとは思えないが… と、疑いようのないものに含みを持たせるのは私の悪い癖かもしれない…
_ 帰ってきてから北町奉行所、南町奉行所を調べてみたら、どちらも 東京駅の八重州口の近くだった。2ブロックくらいしか離れていない。 それなら八丁堀なんて1kmあるかないかじゃないか… 同心の通勤の苛酷さを 思いながら頑張って歩いたのはなんだったんだろう。へたすりゃ最寄りの駅まで 歩いたってそのくらいの距離だからなー
_ Joe のインタビュー (6章) を再度読み直している。
Seibel: Are there any other characteristics of good programmers? Armstrong: I read somewhere, that you have a good memory to be a reasonable programmer. I believe that to be true.いいプログラマになるためには記憶力が必要だとどこかで読んだことがある、 と言っていながらどこで読んだのかを覚えていない、というジョークをJoeなら やりかない気がしてしまうのだが…それは読みかたが歪んでいるのだろうか… ともあれ記憶力は大事だと私も思う。私は技術的な事柄や、 仕事に関する記憶力は周囲の人よりよいつもりでいるのだけど、 それは単に他の人が覚える気がないというだけなのかもしれないし、 自身の記憶力が少しずつ衰えていることも感じるので気をつけなければいけないと 思っている。
_ 昨日は雨あがりだったということもあり短かめにした。清澄白河で折りてから歩く。 そのまま北に歩くと京葉通りで、あとはいつも通り… で、50分くらいかかった。 4kmくらいだろうか
_ 雑音ばかりであまり進んでいない。が、ひとまず Kotlin Bootcamp for Programmersを終えた。 Androidに進もうかとも思ったが、 Refactoring Kotlinをおすすめされたのでそっちを少し見てみる。 Javaっぽい書きかたをKotlinっぽい書きかたにするにはどうすりゃいいの、というような 内容らしい。… そんなにボリュームがないのでひと通り眺めて完了とした。
_ Kotlin/Nativeで試しにEXEを作ってみた。Hello, Worldで1.4MB、 依存するDLLはkernel32.dllとMSVCRT.dllだった。 バックエンドはMinGWみたい (作成されたディレクトリから判断しているだけ) だが、 MSVCRTに依存するんだっけ？ … 普通にgccでビルドしても同様なので、そんなもんらしい。
_ Cinteropというのがあるらしい。そしてARMのバイナリも吐けるようなので、 ひょっとしたらGoと同様にクロス開発ができる…かもしれない？ ただHard floatじゃないとだめ？ なように読めないこともない。 ターゲットのデバイスはSoft floatなのでむりかな
_ たまたま近くにRasPi3を転がしていたのでそちらで動かしてみた。 stripしたら200KBちょっとだった。とくに問題なく動く。 ただコンパイルが盛大に遅いなあ
_ こちらもさほど進んでいない。
_ JupyterでF#が使えるのが便利。 以前はF#を手軽に試すことができて便利。だったのに対して、 F#にちょっと慣れてきた最近はJupyterの機能を活用するにあたりF#が使えて便利、 というように、便利に感じる内容が少し変わっている。いずれにしても便利
_ 先日の1回休みのときに Scott Wlaschin - Talk Session: Domain Modeling Made Functionalと The Power of Composition - Scott Wlaschinを見た。 後者はこのひとの一連のプレゼンの中ではかなり基礎的な話なのでとっつきやすい。 前者は、関数型言語と型をどうあつかってゆくといいのかという戸惑いにいろいろ ヒントを与えてくれる内容だった。
_ やっぱり読み上げをさせたい。アプリ＋Talkbackだとうまくないし、 AndroidのChromeは期待通りにページを読ませることがうまくできた試しがない。
_ Windows10だとどうかな？ どうやら「ナレーター」という機能で読み上げが可能らしい。 視覚障害者向けの機能だとは思うんだけど、けっこうショートカットキーが 駆使されているようで、有効無効を切り替えるために Windows+CTRL+Enter と すでにハードコアな組み合わせを求めてくるあたりがすごい。 コンテキストに依存する操作よりもショートカットキーのほうが効率がいいのかもしれないが…
_ O'Reilly Learningのebookで試してみたところ、読み上げの具合も悪くない。 精度は申し分なく、読み上げ位置をきちんと画面内におさめてくれるような制御も してくれるので、長めのページであればそのまま放っておいて読みつづけるといったことが 可能なようだ。たまに前触れなく読み上げが止まってしまうことがあるものの、 再開すればまた読んでくれるのであまり大きな問題ではない。 これならWindowsタブレットでもいけるかな？ ArrowsTabで試したところ、 どうも読み上げスピードが一定しない。読み上げ自体のスピードは遅くないのだけど、 「間」を感じることが多い、と言ったほうが正確だろうか。 3〜4語ごとにその「間」を感じるので、せっかく読み上げスピードを上げてもあんまり 速くない。ArrowsTabでこの調子だとすると、それよりも性能が劣るLavie Tabではさらに 悪い成績になるかもしれない。あとで試す。
_ 読み上げが安定してできるようになるとかなりよい。 今ちびちび読んでいるCoders at Workも読み進めるのが楽になるし、 この手のインタビューものや、技術系エッセイみたいなものの消費を進めることができそうだ。 O'Reilly LearningにはJoel SpolskyやPaul Grahamの本が収録されているので、 当分読むものには困らないだろう。他にもコードが少ない技術書ならどんどん読んでゆけそうだ。 幸い都心に勤務している身であり 地下鉄の中も含めてネットワークにつなげることができない状態はほとんどないので、 アプリで頑張るメリットがあまりない。けっこう最後に読んだ場所を忘れてくれるときも あるし… Sync Positionすると復活するときと、しないときがある。
_ ナレーターキー (デフォルトだとINSまたは無変換が) を中心としたショートカットキーを 繰り出そうにも、ソフトウェアキーボードでできるのか？ そもそもナレーターキーにアサインされているキーとの同時押しを想定しているようなので むりっぽい。 タッチ操作でもできるみたいだけど なかなかのアクロバティックな操作を要求されているような。 あとマルチタッチ対応のタッチパネルじゃないとだめそうだ。Lavie Tabはどうだったかな… それとArrowsTabだとナレーターを有効にしつつChromeを使おうとすると けっこうな頻度でディスプレイドライバがいやんなことになってログイン画面に戻されてしまう。
_ …Lavie Tabで試してみた。悪くない。ArrowsTabで感じていた挙動不審さもないし、 読み上げのぎこちなさもあまり感じない。試した本がよかったのかもしれない。 ArrowsTabのときはプログラム関係の本だったので、ボールドやイタリックや コードなどが入り混じっていてハンデが大きかったのかも
_ 平成が終わってもまだこのソフトを使っているというのが不思議な気分だが 他に替えがきかないままの状態なので仕方ない。 カーネルのデバッグに使うというよりはSOS拡張を使って .NET のデバッグをするケースが多い。とくにメモリが絡むやつは これが一番調べやすいように思う。
_ とはいえ道具だてをきちんと把握できていないので、手作業が多い。 もうちょっとスクリプトとかプログラム言語的なもので解析を進めてゆきたいところなのだが…
_ Cisco-Talos/dotNET_WinDBGから辿れる Talos Blog || Cisco Talos Intelligence Group - Comprehensive Threat Intelligence: Unravelling .NET with the Help of WinDBGを読むと、 pykdというやつを使ったりできるようだ。 あと、 JavaScript のブリッジにより、WinDbg でのマルウェア分析が容易に (Cisco Japan Blog) に書かれているような手法もあるらしい。 Debugger Data Model C++ Interfaces Overview - Windows drivers | Microsoft Docsというのがあるようだ。
_ 知らないだけでやりようはいくらでもあるみたい。 WinDbg自体もいろいろ垢抜けつつあるようだけど、それ以前にWinDbgをエンジンにして 自分の望む解析をするというアプローチをきちんと理解しておくべきなのかもしれない。
_ そういえばここで公開されている SOSEX というのが SOS よりも便利に使えるらしいという 話をMicrosoft Pressの何かの本で読んだことがあったのをふと思い出した。 何かの強化版にEXをつけがちだけど末尾に注意だなあ〜 というような変な記憶のひっかかりかただった
_ 電車で向かいのシートに座っていた人が読んでいた本がこれを扱ったものだった。 アウトラインプロセッサやコルクボードや、いろいろが統合されたアプリケーションらしい。
_ 自分で使う気はないものの、執筆環境の改善というのは長いこと進んでいないなあということを 思い出すきっかけになった…。 テキスト編集環境、それをレンダリングする環境、文献の管理、素材の管理、などなど…
_ Python→Go→F# と作ってきたアプリに似たものをC#でも作る。実験というよりは 必要になったから… なんだが
_ F# ではシーケンス中心に書くのが比較的よい結果にむすびついていたので、 試しにC#でも似たようなことやってみようとした。 yieldはシンプルなケースでしか 使ったことがない。で試してみたところ、F#における yield! がないので なかなかしんどいかもしれない。再帰的に使おうとしないほうがいいのかもしれない。
_ そんな小さな挫折をしながら書く。すぐにinterfaceやdelegateがたくさんできてしまった。 そして機能ごとにくくり出したクラスたちが相互に依存しはじめて、その面倒を見るクラスが 増えて… と、書けば書くほどもやもやが増えてゆく。
_ 昨晩〜今日にかけて雪かも？ という予報だったけどとくに降らなかったようだ。 冷たい雨が降っている程度。明日はいきなり気温が10度くらい上がるらしい。 めりはりがあってよい
_ サーバが固まって操作できなくなったのでやむなくPowerOff→Onした後にログを見てみたところ…
Jan 28 17:55:19 localhost kernel: [ 292.635629] VERIFY3(0 == arc_buf_alloc_impl(hdr, private, compressed_read, B_TRUE, &buf)) failed (0 == 0) Jan 28 17:55:19 localhost kernel: [ 292.635636] PANIC at arc.c:5297:arc_read() Jan 28 17:55:19 localhost kernel: [ 292.635638] Showing stack for process 18231 Jan 28 17:55:19 localhost kernel: [ 292.635641] CPU: 8 PID: 18231 Comm: grep Tainted: P O 4.15.0-76-generic #86-Ubuntu (以下略)うわああzpoolがあああ、となった。ところでこのVERIFYは 0 == 0 で failed となっているが それは failed なのだろうか？ この行のメッセージで検索かけてみたところいくつかissueを見つけた (たとえばこれ)… が、 原因やら解決策がないままcloseされているような
_ それにしても前回ZFSのおひっこしをしたのが去年の9/4で、 なんか不調になったのが9/14… そして今回リストアしたのが1/19 なので… このシステムは寿命が10日しかないのかもしれない。 なお再起動したところ普通に起動はしている。
_ 0 == 0 の件は これ らしい。もう1年以上前に直したと言っているが…
_ ZoLだけのことを考えればLTSにこだわらずにどんどん上げていっちゃったほうがいい気もする。 今は19.10というのが最新らしい。ただ19になるとKernelが5系に上がるんだよなあー
_ 昨日破産したらしい。 米沢は何年か前に閉店していたのでべつに驚くことでもない… と思ったら大沼本体が破産で ぜんぶ閉店だったのか。記事を追ってみると21世紀に入ってからの経営の問題とその 立てなおしがことごとく上手いこと行っていない感じを受けた。
_ 山形にいた頃に大沼を利用したことはないし、米沢にいた頃も数えるほどしか入ったことがない。 21世紀入って早々の段階で、地元でない人が入口を一瞥しただけで寂れていると 見抜かれるような、そんな感じだったので、歴史のある建物や事業がなくなってしまうという 寂しさはあるものの、不便になったわーという感覚はない。そもそももう米沢にいないし…
_ 表記が一定しないが正解がわからんので仕方ない
_ 読みたい本は増える一方だが読むスピードが遅くていけない。 読むスピードを一定にするには読み上げの力を借りるのが効果的だとは思う。 それで読むスピードも多少は上がるとは思うけど、読み上げのスピードに制限されているので、 いわゆる流し読みの能力はそれはそれで上げないといけない。
_ 流し読みの能力を上げるにはどうすりゃいいんだろう？ 一定のスピードで強制スクロールとかページ変更とかさせればいいんだろうか… スクロールは目が疲れそうだからページ変更かな？
_ 今のところ積読状態になっている本が20冊を超えていて、日に数冊増えており、 一方でそれなりに消化できるために1冊あたり2〜3日はかかるので大変によろしくない。 そもそも読み放題なのに積読というのはよくわからんが、いずれにしても 自分の中の待機リストに入っているというのは確かだ。「それなりに消化」は、 流して読んでいって、最後まで読み通すとか、途中で読まなくていいと思ってやめるとか、 そういった処理ができた状態を指している。読みたい本が後から後から増えてくる…という 状態がこの先ずっと続くわけではないだろうから、このような消化のスピードを 上げつつ、いったんは待機リストの本を流してみるという感じになるだろうか。 まあそもそも読むための時間をあまりとれていないというのもあるが…
_ REGALを扱っている小売店で2足買った。ひとつはゴアテックス配合 (？) のやつで 兼ねてから欲しかったものだ。もうひとつはセールで半額だったので衝動的に買った。
_ 今朝は雨あがりでまだ地面が濡れていたこともあり、ゴアテックス配合のやつを試してみた。 まだ革が固くて靴ずれしそうな気がするなあ、これで家まで歩いて帰るなんてことが できるのだろうか… と心配になりながら駅まで歩いた段階ですでに靴ずれを起こしていた。 踵の少し上のところ。馴染むまでは大変かも。
_ 上げてしまった。どうせ本稼動していないサーバだし18.04LTSの段階でFreeNASとの znapzendによるバックアップは頓挫しているので、 遠慮する必要はないだろう
_ で上げ終わってから再起動したら2つあるはずのpoolがひとつしかない。 rpoolが普段つかっているpoolで、bpoolはBoot Environment的なpoolにしているんだが… dmesgを見る…
zpool[1405]: cannot import 'bpool': pool was previously in use from another system.ひえええ
_ インストール終わってからexportしてないということだろうか？ いやしていなかったとして なぜanother systemという判断になっているんだ？ わからん。わからんが zpool import -f で インポートしてしまった
_ あとaptで入れていたsynergyが消えてしまった。なんでだ？ しょうがないので ソースからビルドする。 cmakeはたまに少し使う程度なのでいつまでたっても使いこなせている感じがしない。
_ ビルド自動化というあたりではだいたい指定されているものが多いので 気付かずに使っているものも多いかもしれない。Rustならcargoだし .NET Coreだとdotnetだし、Goならgoだし、あとAndroid Studioだと Gradleになっていたような気がする。Ninjaというのも意識せずに使っているのかもしれない。
_ 意識して使うのはあいかわらずmakeが多い。なんとなくMakefileをちょっと書いて動かして‥ という人生を30年近く過ごしてきたし、Ninjaというのは手で書くことを想定したものでは ないようだし…
_ Build script generation は、昔はautotoolsを一生懸命使っていた気がするが なかなか馴染めないものがあった。Xが絡むやつはimakeがすっきりしていて分かりやすかった 記憶がある。ここのところ元気なのはやはりCMakeなのだろうか？ CMakeは自力でCMakeLists.txtを書けないし、書けるようになりたいと思ったことがない。 でもBuild script generation を使ってコードを構成する必要が発生したときに 再度autotoolsに戻れるかというとそんな気はしないので、CMakeを使うことになるかなと思う。 そしてBuild script generation を使ってコードを構成する必要が近々に発生しそうなので、 いろいろ予習しといたほうがいいのかも…
_ 靴ずれ部分にキズパワーパッドのクローン製品を貼ったところ、傷の回復をしつつ 靴の攻撃を防ぐことができて大変に具合がよい。しかしこんなことをやっていても 少なくとも私の足の方が馴染むのに時間がかかるだけかもしれない。 先に靴が馴染んでくれればいいのだが
_ とりあえずどのくらい積んでいるのかを残せるようにシートを作った。今のところ 待機リストは80。 1ページが長くてコードや図表が少ないものは電車の中などで読むことにして、 あとは実際に手を動かしながら読まなきゃいけないものと、とにかく流して読んだほうがいいもの などといった分類をあらかじめしておいて、状況に応じて今取り組むべき本をすぐに 決定できるという仕組みにした。
_ そういえば以前買ってほとんど取り組めなかったCTMCPは、 O'Reillyには収録されていないようだ。どうも MIT Pressの本が収録されていない？ように見える。 しかしACMの特典で他のサイト、具体的にはSkillPortというサービスにもアクセスできて、 そっちに収録されていることが分かった。軽く読もうとしたが… Webインターフェースがとっつきにくい。出来が悪いのではないか？という気がしてくる。 O'Reillyのものも決して褒められたものではないように思うけど、読む気が失せるほどではない。
_ 昨日も歩いて帰ってみたところ、キズパワーパッド的なもので守られているところは あまり悪化せず、新しい靴ずれができたもののそこまでひどいものではなかったので、 まあこの調子で頑張っていれば慣れそうだ
_ なんとなくKotlinのカーネルも入れてみた。REPLがあるのでちょっと試すときは そちらでいいんだけど、ちょっとじゃないものを試すにはJupyterの方がいい気がしたので。 F# は F# Interactive で不足を感じたらスクリプトにすることもできるし、 Jupyterを使うこともできるので大変によい。
_ Jupyterの後継はJupyterLabというらしい。 いろいろ拡張しやすい作りになっているようなので期待。 jupyterlab-lspなんてのもあるので、 汎用的なコード補完なども期待できそう。
_ VSCodeの中でNotebook的な操作ができるらしい。やってみたらできた。 すごいじゃないか。コード補完なども普通にできるし。
_ ただカーネルはPython固定？ のように見える。F# でこれできたらさらに うれしいんだが…
_ 最近はMLというとMachine Learningの略として使われることが多いみたいで、 最近F#にとりつかれている私としてはウホッMeta Languageの話題かと思って辿ってみたら Machine Learningの話でがっかり… という結果になる。 さすがに文脈からMailing Listと読み間違えることはないが…
_ キズパワーパッド的なもので守られていたはずの左かかとがなんか痛いし、 フロ入ったらしみるし、どうなっているんだ…？と見てみたらキズパワーパッド的なものに 穴が開いていた。 この先この靴とうまいことやってゆけるんだろうか
_ そんなこともあって今日は昔から使っている靴に戻ってみた。ストレスフリーの履き心地で 非常に楽だ。
_ まとまった時間がなかなかとれないので空いた時間でLeetCodeをやっている。 しかし空いた時間だけでできるわけではないので進みは悪いし結局それなりに時間を とっているような気がする。
_ Add Two Numbersを、何度もひっかかりながら通した。LeetCodeだとコードの実行が 遅いのでTry and Errがやりにくい。なのでJupyterに持ってきたのだが、LeetCodeで 通っているコードが通らなかったりする。今回のケースではListNode.next が varなので Smart Castが通りませんよ、と、手元では怒られるんだがLeetCodeでは通ってしまうといった 症状だった。
_ 今回の問題ではまあ再帰でやるだろうな… と思ったので下請け関数を作って、 引数ひとつ増やして… とやっている。で 再帰的に呼ぶ際に .next をつけて… とやったんだが、 そのときに構築中のListNodeが、ここで非nullにセットしているつもりかもしれんが ここでも非nullとは限らないぜ、なぜならvarだから、ということになってしまう。 それ自体はもちろん理解可能な動きなんだが… ということでちょっとした苦労があった。 それと、null だったらreturnしてしまって、以降はnullじゃないときだけだよね、 と思ってもそういうSmart Castはないらしい。まあそんなもんか
_ Jupyterで試すのは軽快な動きでよいのだけど、コンパイルエラーが分かりづらい。 しょうがないのでコンパイルエラーが出たらコード全体をIDEAのREPLにペーストして… などとやっているのはちょっと間抜けな感じがする。最初っからREPLでやったほうがいいのだろうか？ Jupyterだと記録やメモ残しながらできるので本当はこっちの方がありがたいのだが…
_ Nullable の状態をなるべく保ったままロジックを書くのがいいのか、 非Nullの状態にさっさと確定してしまったほうがいいのかで悩む。 Nullable のままにしておいて、 ?. でつなげてゆくと F# の Option みたいな感じにできて よい気もしつつ、あんまりつなげていると何処で失敗したのかが分からんという問題もある。 F# だと Result というやつで失敗のときの情報を渡すこともできるので、気にせずどんどん つなげてもよいと思う。
_ どうも関数型言語的な書きかたをするとタイムアウトになってしまうことが…私の作りかたが へたっぴなだけなのかもしれないが、普通に変数使ってループまわすとあっさり終わる処理を 再帰とimmutableなコレクションベースに書きなおすと大変に時間がかかる。 テストケースの中にはものすごくでかい入力データなんてのもあるので、これを通るように するためには仕方ないのかもしれんが…
_ C# における out/ref みたいなのはないのか。 内部状態を更新しつつ処理を進める、みたいなことが複数箇所にある場合にそれを 関数として括り出したい場合はlambdaを使うしかないのかな？ PairやTripleと、Destructuring Declarations を組み合わせるという方法もあるが あんまり見通しがよい感じがしない。
_ F# も Go も Kotlin も、いろんな記号の組み合わせを演算子などとして使っているのでいろいろ混乱する。 その記号の組み合わせを見たときに即座に意味が了解できないという問題ももちろんあるし、 同じであったり同じような組み合わせが言語によってまったく違う意味だったりすることもあるので大変だ。 F# だと :? は型のマッチングをするための演算子で、 Kotlin は ?: というのがあってまったく働きが違う。 もっともこれに限っては、後者にはElvis Operatorという愛称がついているので 辛うじて混同せずに済んでいるという感じだ。
_ そういった記号の組み合わせには、! とか ? が使われる割合が多いような気がする。 あんまり ! を多用すると最近の30前後の若手の書くビジネスメールかよという 印象を受けてしまいがちだし、 Int? などという記述を目にすると、 もっと自信を持って! と言いたくなってしまうのだが、 それらはいずれもこちらの感受性の問題なのかもしれない