Zinnia hacks tomorrow. (2020/3)

2020/03/01 (Sun)

_ 今日は東京マラソンだった。すっかり忘れていた。 通行規制はあったものの観客はほぼまったくいなかった。一般参加もないし、 以前の選考のための大会とはコースが違うようなので会社の前は静かなもんだった。


2020/03/06 (Fri)

_ ここのところ酒を飲まずに睡眠も多めにとっているんだが、どうも頭痛がおさまらない。 目が疲れているというのもあるかもしれない。そのため目を酷使する作業がなかなか進まず、 しかしやらないとまずいので無理してやって、また悪化しているというような


= Not a square to spare: Australian shops ration toilet paper amid coronavirus panic - Reuters

_ トイレットペーパー買占めは日本固有の現象ではなかったのか。


= 買占め

_ 必要なときに使えないのは困るので、買えない時期が長く続く可能性を考慮して備蓄しておきたい、 というのは自然な発想だと思うが、 転売目的の買占めを法的に処罰できるような流れになってゆくらしい。 この手の買占めの話を見るたびに、買占めを合法的に止める方法はないもんか?と 無い知恵を絞ってみるのだがとくによい考えが浮かんでいない。かといって新しい法で 縛るというのもどうなのかねという感じはする。

_ 買占めを抑制するには買占めが割に合わない行動であるという状況を作ることが 必要なんじゃないかと考えている。そのためにはどうすればいいのか? 売れない、というのがまっさきに思いつくものだ。 買うつもりがない人が入札して支払いをせずにキャンセルして、 なんていう対抗措置をやっている人がいるようで、 それも売れない状態をつくる行動のひとつだろう。ただその対抗措置そのものが 法律や規約に反している可能性は高そうだし、債務を負ってしまうことも起きるだろう。

_ 次に、転売目的で買占めをする人のソーシャルネットワーク的な評価を下げるといったような 発想がある。実績を元に信頼度を築いてゆくという仕組みがうまく働いているのであれば、 別人になりすますことはいつまでも信頼を高めることができず結局物事がうまく進まない… このあたりはソーシャルネットワークで不行跡をすることが割に合わない理由として よく挙げられているけど、そこまでうまく行くものだろうかという気がする。

_ といったあたりでだいたい堂々巡りになってしまい、まして個人でできることはないような 気がするなあ… という感じで終わってしまう。 「風説の流布」は、有価証券の価格を操作する目的でないとだめなんだろうし、 しかし一方で転売して儲けることを目的にデマを流しているとしか見做せないような 行動をしている人もいるので、流通を混乱させて価格を釣り上げるなんてのは 既存の法の中でどうにもならん問題なのだろうか? という違和感や無力感がある。


= Facebook To Revamp Libra | PYMNTS.com

_ 最初に見たときは仮想通貨からPayment networkにシフトする的な見出しだったと思うんだが あらためて引用しようとしたら変わっていた。本文はだいたいそんな感じの内容のままだ。 仮想通貨であってもPayment networkであっても、別にFacebookにそれをやってほしいとか、 Facebookがやったらこんなすごいことがといった予感とか、は、まったくないのでもともと 関心が薄い。Libraは米国の議員のオモチャにされているようにしか見えなかったし…



= 最近のF#

_ Subversionのブランチの状況、具体的にはどんなブランチがあって、 それらのブランチポイントはどこで、その後どういう修正をしたのか、みたいな 系統図を作ることになり、VisioやらPowerPointやらExcelやらで作れないこともないが、 やはりマークアップ的に記述しておきたいというのと、 細かく出したり大まかに出したりといった詳細レベルの制御を後からかけたりできるようにしたい という欲求があり、そういったことができそうな枠組みを探した。 GraphVizなどを使うのが妥当なのだろうか? と思いながら、どうもしっくりこなかったので さらに探したところ GitGraph.js というのを発見した。 これをうまいことやればうまいことなりそうだ。sandboxでいろいろ試したところ いけそうな感じだったので実際に取り組んでみた。

_ 入力になる系統図は半自動というのか、たとえば 対象のrevisionの番号は手で入れるが、そのcommitされた時刻は勝手に補う、 といったような作りにする。 コミット1つ分を表現するrecordと、ブランチを表現するrecordを作り、 Computation expressionsを使ってそれを入力しやすいようにした。 Computation expressionsの機能の限界を使っているわけではまったくないが、 この組み合わせはたいへんに便利だと思った。外でjsonやらyamlやらを作るよりも楽ちんだし、 中でコード書いたりもできるので大変によい。

_ 日付をとってくるのはsvnサーバに直接問い合わせて… だと遅そうだしサーバに 迷惑をかけそうだったので、svn log --xml でとってきたものを読むことにした。 それはそれで負荷がかかるが1回きりなのでよいだろう。一部を抜粋したxmlを用意して、 それを使ってType Providerで型を作った。何度触ってもすごい仕組みだな。 便利すぎてあほになっちゃいそうだ

_ あとはとってきたデータたちを元に作図をするためのjsを生成させて、 htmlから呼び出して、だいたいやりたいことができた。まだ慣れていない部分で 少々手間どったものの、わりと短時間で望むことができたように思う。

_ それに加えて、無理のない実装ができる、というのか、 本当はきちんと書かなきゃいけないんだけどさっさと書きあげたいので手抜き、みたいな 妥協をしなければいけない場面がほとんどない。やっつけで書いて 拡張しづらそうな感じ、ということもない。F# は本当にいろいろパワフルだなあと思った。 書くことそのものが楽しいというのはErlang以来の経験だ。2010年代はErlangに夢中だったけど、 2020年代はひとまず F# 一色になるかもしれないなあ〜 とりあえず F# 5 が出るまでに もっと手に馴染ませておきたいところだ。

_ 通信とかバイナリデータが絡むものについてはあいかわらずErlangに手が伸びるけど、 それ以外の用途ではほぼF#でいけそうな感じがしている。 Pythonに手が伸びることがほとんどなくなった。本当はC#を触る回数も減らしたいところだが、 さすがにそういうわけにはいかないケースも多い。 Scott氏の Twenty six low-risk ways to use F# at work | F# for fun and profitなどを参考にF#の出番を増やしてゆく感じかなあ〜


2020/03/09 (Mon)

_ 土曜は出社せず近所の犬たちとたわむれたりして過ごした。 そして久しぶりに (といっても3〜4日ぶりくらいだけど) 酒を少し飲んで寝て、 日曜の朝に目が覚めた直後からなかなかの強度の眩暈がはじまり、まっすぐ歩くのも大変という 感じになったので1日中家で横になっていた。洗濯機をまわすだけでもあちこちぶつかるような始末。 夕方には少しましになったけど本調子とは言えなかったので食べるもの食べてそのまま 寝つづけた。

_ 昼と夜はそこそこ喰った。喰う前は吐き気も少々覚えていたんだが、腹は減っていたし 頭痛薬も飲みたかったので喰った。喰ったそばから吐き気が悪化するということもなく 普通に喰えた。

_ で朝目が覚めたところ、完全になくなったわけではないが眩暈はおさまり、強めの頭痛が 残っていた程度なので出社した。


= 最近の低温調理

_ ジョンが来たときにいったん片付けたので、1ヶ月ぶりくらい? 低温調理+揚げ物というのをいっぺんやってみたかったので試した。具体的にはトンカツだ。 低温調理の段階ですでに加熱は終わっているので、あとは衣をつけて揚げ色がつくまで 揚げるだけ…だと思う。 とはいえトンカツというのは作ったことがない。そもそも揚げ物というのは数えるくらいしか やったことがない。鳥天くらいか? 記録を見てみると2000年のことらしいのでZHTにも出ていない。

_ せっかく低温調理なので分厚いものにしたい。一方で衣がくっつくかどうか まったく自信がなかったので、失敗が少なそうなバッター液+パン粉という構成でやってみた。 1回目 (自分が食べる分) は、そこそこうまくいったんだが、2回目 (妻が食べる分) は、 ほとんど衣が定着せずにぼろぼろだった。油の温度の違いだろうか。 1回目はちょっと高目にしたところ、けっこう水分の蒸発が急で、 つまり吹きこぼれそうになったので2回目は少し低めの温度で試したのだった。 あとはパン粉をつけてから揚げるまでの時間差もあったのだろうか。 バッター液を纏っても、パン粉に吸われてしまっては意味がないのかもしれない。 あとバッター液が緩かったのかもしれない。いろいろ見直す余地はありそうだ

_ ともあれ味は悪くなかった。せっかく低温調理なので (しつこい) ぶ厚くしたのだが いくらなんでもぶ厚すぎたかもしれない。もうちょっと控え目でもよかった。

_ バッター液とパン粉と千切りのキャベツがそれぞれ余ったので、かつおぶしを加えて 全部混ぜあわせて味気ないお好み焼き風のものを作って食べた。ソースがあれば全然いける


_ おさまったと思っていた眩暈が夕方からまたはじまった。 昨日ほどひどくはないが… PCに向かっているのが少々苦痛な程度にはひどい。

_ 眩暈がひどいのとひきかえに、耳鳴りの音量が少し下がったような気がする。 そう考えてみると、眩暈が始まる前の数日間は耳鳴りの音が強くなったような気がする。 耳鳴りが強くなる→眩暈が起こり耳鳴りが少し小さくなる? という感じ。いずれにしても いっぺん病院に行ったほうがよさそうだなあ


2020/03/10 (Tue)

_ 久しぶりの朝練。さすがに週末寝すぎたのか早く目が覚めてしまったのでそのまま出社した。 今日はあまり寒くないようで電車の中は暑いくらいだった。

_ 眩暈は感じない。頭痛はあいかわらずあるが… 目が覚めた瞬間から頭痛というのは なかなかめんどくさい展開だ。もちろん初めての経験ではないが毎回嫌になる。


= 今日のF#

_ 先日Computation expressionsのbuilderを手作りしたり、 Type Providerを使ったり、とF#らしいことをいろいろした。 WikiBooksを読み直して、他にF#の機能であまり触っていないところがないかを探してみた。 まずクラス関係。ほとんど使っていない…が、必要になる機会を見逃すことはないと思うし、 そのときに自然に取り組むことができると思うので慌てて使うこともないだろう。 Active Patternsは、どういうものかは分かったし便利そうなんだけど、自分が取り組んでいる 内容について今こそActive Patternsを使う時だ! みたいなイメージがない。まあ、 できることは理解したので、いつかピンと来るのかもしれない。 あとはやはりasync関係か… 使ってないことはないんだが全貌が見えていない感じがする。MailboxProcessorを絡めた 非同期処理のidiom的なものがまだ掴めていない。

_ MailboxProcessor でメッセージキューっぽいのができるのでよいのだが、 コールバックの中で処理を進めることができそうもない場合、たとえば他のコールバックの 中で使いたいとか、で困っている。外側でBlockingCollectionなどを作っておいて そっちに渡して、さらにそれを別のコールバックでTryGetして… などとすれば ひとまず目的は果たせるんだが、結局ブロックしているだけなので asyncのよさがだいぶ失われているし、複数の待ちを同時に実現することもむずかしい。 それぞれにAutoResetEventなどを使うのも、なんだか無駄な気がする。

_ MailboxProcessorのコールバックの中でReceiveをしているという例ばかりを 見掛けたけど、逆にコールバックの中でPostして、外側でReceiveをするということは できるのかな? 試した限りではちゃんと動く。実装を見るとMailboxはQueueと AutoResetEventを組み合わせて実現しているようなので、とくにどのワーカースレッドが 受信/送信なのかは問題にならないように見える。

_ How to implement server-push over websocket in suave? - Issue #307 - SuaveIO/suave - GitHub。 やりたいのは要するにこういうことだった。ここのやりとりを見て 真似をしたらうまくいった。asyncの中とsocketの中ではlet!やdo!の呼び出し先が 変わるので、asyncの中からWebSocketのsendを呼ぶときにどうやって受ければいいのかが よくわからなかった。ので助かった。そして Async.Choose というので複数のAsyncを待つことができることを理解した。 SuaveのWebSocketではうまくいかないようだが…

_ ともあれ、いじりはじめる前の腑に落ちない感じはだいぶなくなって、 これなら書き続けられそうという感じになってきた。これでもともと書きたかった 内容を書いてゆけるだろう。

_ ページをいきなり閉じたときはWebSocketのメッセージとしては飛んでこなくて、 Suaveの中でSocketError ConnectionAbortedというログが出ている。 これhandler側で掴めないといろいろ漏れそう。ドキュメント見れば解決するはずだが… wsWithErrorHandling を真似すればよさそう

_ F#がいろいろ手に馴染んでくると、あまりGoの出番がなくていつまでも慣れないという 問題が残る。Erlangはこの先もどんどん使ってゆくつもりだし、 C#は避けようにも避けられないし、KotlinもAndroidを触るときには避けられないし、 Pythonは、もう10年近く使っているのでしばらく使わなくても問題ないだろう。 そう考えると意識して使わなきゃいけないのはGoくらいで、今のところ 組み込み端末向けの言語としての評価をしたい…で止まっている。ある程度手に馴染んだら 再チャレンジするつもりだったのだが、この調子ではなかなか慣れないだろう。困ったもんだ


2020/03/12 (Thu)

_ 火曜の午後から1.5回休みだった。 体調はあいかわらずよろしくない。

_ 休み中はあまり創造的なことはしなかった。 ただIntroduction ― Vue.jsを 読みつつそこからリンクされていた Vue Masteryの Intro to Vue.js を見たりした。


= Anki

_ 英語に関する他の取り組みが滞っていても、Ankiは続けている。別にまとまった時間が 必要なわけじゃないので横断歩道の信号が変わるまでとか、ホームに電車が入ってくるまでとか、 隙間の時間にこなしている。

_ もう3年近くになるが、英語学習についてまとめたときに あまりAnkiのことを書けなかったのが心残りだった。 やりかたを間違えると効果が薄くて無駄が多い、ということに苦しめられることになるが、 それを書くことができていなかったのが心残りの理由だ。

_ 注意点としてまとめると非常に簡潔な話で、1) 1日に投入するカードをあまり多くしない、 2) 新しく投入するより復習を優先する、3) 回答後の自信度は正直に答える、という3点になる。

_ (1) は、たぶん始めてすぐに気付くと思うのであまり問題ないかもしれない。 取り組んですぐ、2〜3日は、まだ復習のカードがほとんど 出てこないので、新規投入されるカードの枚数=1日に取り組む枚数といった発想で 設定しがちであるが、すぐに大量の復習カードが押しよせてくることになる。 1日に復習するカードの数量制限をすることは可能だけど、それは本来想定した復習の間隔よりも 先延ばしするということなので、効果が薄れると思う。

_ (2) もだいたい同じ理由… というか(1)〜(3) はすべて「自信がないカードが復習のキューに 大量に放流されると収拾がつかなくなる」という問題に帰着する。 よくわからないカードが多いデッキでは、新しいカードに取り組むよりも、1日あたりの 復習が数量制限に達しないように復習を優先したほうがよい。

_ そして (3) だが… この自信度をもとに再度問題が出てくるまでの期間が決定して、 それが学習曲線的によい、という理屈はもちろん理解していたが、それでもよくわからない カードが連続して出てくるようなデッキで、本当は分かってないが「もう一度」を選ばずに その隣の「難しい」を選んでしまい、「難しい」を選びつづけて学習間隔が1ヶ月を超えたら 「もう一度」を選ぶ、なんていうマイルールで運用してしまっていた。 「もう一度」が連続すると「無駄」としてマークされてしまうので、なんかそれはいやだなあと 思った結果の行動だった。これによって、さらによくわからないカードが放流されることになり、 復習待ちのカードが大量に出来た結果、もはや想定した間隔で復習することなど できないような状態になってしまった。

_ ということで、自信度は正直に答えたほうがよい。「もう一度」が一定回数連続すると 「無駄」マークがついてしまうのだけど、同じ日の復習であれば何度「もう一度」を選んでも 1回としかカウントされないようなので、よく分かっていないのに「難しい」を選ぶくらいなら、 分かるまで「もう一度」をしたほうがよいし、その運用でなお定着しないようなら いったん保留したほうがよい。とにかく復習の間隔を設計通りに進めることが重要だ。


2020/03/16 (Mon)

_ 週末は久しぶりに何もしないまま過ごした。ホワイトデーだったのでいろいろ 料理を作ったりしたくらい。久しぶりに寒くて、この冬はじめての?雪になった。


= ACMの会員証

_ 10日くらい前に届いた。月刊誌の方は先月に届いていたので、ひょっとして 会員証は届かないのかしら?と思っていたのだが


2020/03/17 (Tue)

_ まだまだ寒い。


= Visual Basic support planned for .NET 5.0 | Visual Basic Blog

_ 先日妻に聞かれて最近のVBのことを調べたんだが、今でもきちんと言語の更新が 行われていて立派なもんだなあと思ったのと、VB.NETという表記はもう10年以上前に なくなって今は単にVisual Basicと呼ぶんだなあというのを知ったのと、まあ後者はべつに いいんだが、いずれにしても更新しつづけて立派だなあと思っていたが、.NET 5.0以降は だんだんとそういった更新が止まるかもしれないらしい。

_ 現在のVBは、昔ながら、つまりVB6時代やVBAのような書き方をかなりの部分で 受け入れてつづけており、ADODBとかMicrosoft Scripting Runtimeなんかも使おうと思えば 未だに使えるし、On Error GoTo も使えるし… 一方でそれらとは決別して新しい オブジェクト指向言語的な書き方をすることもできるしBCLを積極的に使うこともできる。 この状態は、私には雑然としたものとして感じられてしまい、あまり好意的に、 たとえば、柔軟性があるといったようには受け止めることができなかった。 未だにVBを使っている企業などはこの状態を求めているんだろうか?徹底的にVB6以前のままで あってほしいという意図の方が強いと思っていたのだが、段階的にモダンなものにしてゆきたいという 欲求はそれはそれであるのかな?

_ 妻に最近のVBのことを聞かれたときにも、どっちに軸足を置いて調べたりすればいいのかで 悩んだ。ASP.NETとか、もはやVB6時代の書き方では書きようがないものであれば 選択の余地がないので楽だけど、そのようなものを書くときになおVBを使うのかというと、 VBの方が要員確保や教育が楽だとかいう要素がない限り難しいような気がして、 今のご時世はかえってVBができる人を探すほうが大変だったりしないもんかしら? と思う。

_ まあ↑のblogにも書かれている通り軸足をVBに長いこと置いている人であれば また感想も違うのかもしれない。私は毛嫌いするほどではないが特に使いたいと 思うほどではないという接しかただったし、そういう接しかたであればもう一生分触ったと 言ってもいいような気がしないでもない。 N88-Basic→Quick Basic が10年くらい、 VB6やVBAが3〜4年くらい、それぞれ経験しているし… まあ今でもOfficeの文書をどうにか するときにはVBAを使うことがあるけど


2020/03/19 (Thu)


= 最近の低温調理

_ 今週前半は妻がカゼ?で伏せっており、昨日復活した際に肉を食べたいと言いだした。 薄切り肉で炒めものでも… と思っていたらステーキがいいということだったので、 しかし低温調理を普通にやると食べるのが深夜になりそうだし、以前から試してみたかった 時短版の低温調理をやってみることにした。 具体的にはみじん切りにした舞茸と水を入れた状態で60度以上の低温調理をする… というもの。 比較として普通に下ごしらえしたものも準備した。62度で30分。買ってすぐの肉を室温に 戻す手間を省きつつ調理を進めるという点では30分程度の加熱でもかなり意味がありそうな気がする。

_ 30分経過後とりだしてみた段階ですでにだいぶ感触が変わっていた。舞茸水のほうはかなり ホロホロになっている。そして水分もそれなりに出ているようだ。 取り出した舞茸のみじん切りと、同じくみじん切りにした ニンニク、タマネギなどと一緒に炒めてバターやワインやコンソメなどで仕立てた デュクセルっぽいものを、少し緩めにつくってソースとして代用してみた。 もっとも私にはきちんとしたみじん切りを完遂するほどの根気はないので、 ミックスベジタブルよりは少し細かいかなという程度しか刻んでいない。 普通に作った方は普通に醤油+ワインでソースにしてみた。

_ 食べ比べてみたところ、普通に作ったほうはそれはそれで悪くない。肉喰ってるなあという 感じがする。舞茸加工の方もおいしい。舞茸はキノコの中では風味が強いほうなので 悪い方向に働かなければいいのだが… と心配していたが、 きちんとおいしいソースになっていたと思う。30分の加工でここまで柔らかくなるのだからすごい。 とはいえ筋にあたる部分はあまり柔らかくなっていなかった。 筋はコラーゲンなのでこのくらいの調理ではまだ柔らかくなるには至らないのだろう。 とはいえ舞茸加工をこれ以上の時間でやったら筋以外が柔らかくなりすぎるだろう。 加熱すれば柔らかくなるのは分かっているが、今度は筋以外の部分が固くなるし… といったあたりの考察は以前リンクした サイトでやっているし、実際6時間以上加熱したときの筋の状態は、 まあ噛むのには苦労しないが加熱調理したときのようなとろける感じはなかったので、 やはり筋メインの調理をするなら長時間加熱か圧力鍋にしたほうがいいのだろう。

_ ステーキだったら今回の舞茸加工で、筋をあらかじめ細かく切っておくくらいで十分かもしれない。 もっとも、あまり細かく切りすぎるとステーキの形を保っていられないようなことに なってしまうので、それはそれでむずかしい。



= 騒音

_ 2週間くらい前にマンションのエレベーターに貼り紙が出ていて、 住人から騒音の苦情が出ているので静かにしてね、というような内容だった。 ここのビルの大家さんはあんまりそういう紛争に介入しない態度を前面に出していたので 珍しいこともあるもんだと思ったが、さて騒音とはどんなもので、 何処から発しているものなのか?

_ 私自身思い当たるのは、上のほうの階で足踏みのような地団駄のようなものが 頻繁に聞こえるというやつくらいだろうか。妻に聞いてみるとあれは電子ドラムの ペダルの音であろうということらしい。以前住んでいたところで隣人にそういう人がいたらしい。 電子ドラムにしてはリズムが単調というか短かいというか、2秒そこそこの足音?と、 数秒のブランクと、また2秒そこそこの… という感じなので、 短かいフレーズを練習しているのだろうか? しかしこの音そのものは引っ越してきた日から ほぼ毎日、毎夜? (昼間もあるかもしれんが普段いないのでよくわからん) 聞こえてくるので 成長のないことだと思ってしまう。

_ で、この音が苦情の原因なのだろうか? それにしては1年以上放置状態だったわけだし… 私自身、まったく気にならないといえば嘘になるが、もともと耳がよいほうではないこともあり 眠りを妨げられるほどの音量ではないし、おかしな隣人にマッチングするのは 今に始まった話でもないし、あまり気にしていなかったのだが…

_ そしてその貼り紙が出た後もその足音みたいなやつは続いているので、つまり 結局のところ何だったのかが分からないままだ


2020/03/21 (Sat)


= 100日後に死ぬワニ

_ 昨日100日目を迎えた。たしか3〜4日目くらいから見はじめて、 毎日19時に更新が入ることに気付いてからは公開されてすぐに見るようになった。

_ 100日後に死ぬということだけが明かされた状態で、 ワニがどういった原因で死ぬのか、まったく分からないまま99日目を迎え、 昨日の100日目に至った。死というものがどういったものなのか、 家族、知人や隣人の死に触れたときに抱く感覚にとても近いものを疑似体験させるものだった。 死に意味があるわけではなく、納得の行く理由があるわけでもなく、適切なタイミングが あるわけでもなく、ただ自分の目の前からいなくなって、 二度と会えなくなる、という後戻りできない瞬間を超えるのが死というものなんだ、 という圧倒的な喪失感。

_ ワニの日常を100日追いかけて、同じ世界で生活したような気分になって、 そして今はワニの死後の世界を生きつづけている… という感覚を抱いているので、 それが作者の狙いだとしたら (そのはずだと私は思っている)、その狙いは見事に 成功していると思った。

_ で、その前後の動きでちょっと炎上しているらしい? たしかに99日あたりで 映画や漫画、グッズの話が出てきたのには少々違和感があったが…商業作家なのだから そういう展開もありかも? というくらいの感想だった。 100日で完結をきちんと見ることができたので、その周辺のものに触れることで何か新しい 感覚を得ることがあるのだろうか? とは思うので、違和感とは無関係に、 余計なもののような感じを抱いてしまう。

_ 商業展開が出はじめたときの拒絶反応は、実況やPのひとが収益のことを口に出して 炎上したころの様子を思い出させるものがある。YouTuberが企業案件をこなしている様子を 見てだいぶ時代が変わったなあと思ったもんだけど、根本的なところで商業に結びつくことの 拒絶反応というのはとくになくなっていないのかもしれない。私も違和感を抱いたのは事実だし。 いずれにしてもタイミングが最悪だったんだろうなーとは思う。


= 今日のF#

_ 急ぎツールを作らなければならなくなり、あまり時間もないしPythonで書こうか…と してみたが、数行書いた段階でやっぱりF#の方が書きやすそうだと思ってF#を採用した。

_ ClosedXML.ExcelでExcelのシートを読んだり、 DotNetZipでパスワードつきのzipファイルを読んだり (System.IO.Compressionのやつは パスワードつきのものが扱えないようだ…)、いろんなデータを読んだり加工したり、 といったことをいろいろとやった。書きづらいところはほとんどなく、 手抜きしたところもあまりない状態で、必要に応じてrecordなんかをきちんと駆使して 元データの構造に合った自然な処理を書いてゆくことができたように思う。

_ Visual Studioは使わずに開発をした。ionideは途中で動かなくなった? ようで マウスカーソルを載せても型のことを教えてくれなくなったりで悲しかった。 VSCodeを再起動したらなおったようだ。

_ 意識してF#を使うようになったので少しずつ手に馴染んできたと思う。 1からスクリプト的なものを書くときにPythonに手が伸びることも減りそうだ。 過去に書いたものを流用するときくらいかな…?


2020/03/22 (Sun)

_ ここのところかなり暖かい。昼はコートいらないくらいだ。 夜はわりと冷えこむのでまだ上着なしというわけにはいかないかもしれん


= Android 10

_ 重くて持て余している会社のスマホXperia Z2だがAndroidのバージョンは 順調に上がっているようで、10が降ってきた。

_ ところでアップデートを促すときの画面が、狙っているのかふざけているのか本気なのか 分からないがひどいセンスだ。docomoのサイトにも画面が 載っている。 正規の画面とは信じられずフィッシング的な何かかと思ってしまう完成度だ。

_ それはともあれAndroidがきちんと上がっていってくれるのはありがたい。 開発をするときに最新のものが必要になることは多い…はず (やってない) なので


= DTrace on Windows

_ あまりupdateがない? GitHubも数ヶ月単位で動きがないようだ。

_ 開発マシンなら入れちゃってもいい気がしつつ、こういうのはきちんとメンテされてないと 攻撃のねたに使われかねんので悩むところだ。攻撃のねたにも使えないほどマイナーな 存在で終わってしまうのは、それはそれで悲しい



= 最近の新型コロナウィルス

_ どんどん広がっている… が、日本の伸び率はさほどでもない。ようだ。 欧州での流行がわりと深刻のようだ。イタリアがえらいことになっているらしい。

_ オリンピックの去就はなんだか日本がギブアップしていないので 次の動きを決定できないような空気になっている?のか?


2020/03/23 (Mon)

_ 寝苦しかったりストレスだったりであまり眠れなかった。


= FreeNAS and TrueNAS are Unifying - iXsystems, Inc. - Enterprise Storage & Servers

_ FreeNASとTrueNASが統合して、FreeNASはTrueNAS COREという名前に変わるそうだ。 TrueNASのことはよく知らないのでFreeNASとコードベースがどのくらい離れているのかを 理解していない。けど統合したほうがよいということはそれなりに離れていたということに なるのだろうか…って、11.3RELEASEの段階で95%が共通になっているらしい

_ 12.0 RELEASEは年内か〜 まだまだ先だな


2020/03/28 (Sat)

_ いろんなことがあって、いろいろあった。泊まりは3日間。 いろいろあるのでまだ続くかな

_ 今日の日中はコートなしでも汗ばむくらい暑かった。夕方になってけっこう寒くなった。 そして明日は雪になるかもしれないらしい。焼き入れか?


2020/03/29 (Sun)

_ いくらでも眠れそうな気がするし、朝起きれそうな気がしない。

_ 喉が痛くなってきたような… 気がする。それにしても今回の冬はまだカゼらしい カゼをひいていない。コロナ騒ぎで衛生的になったせいだろうか


=

_ わりときちんと降った。といっても時間は短かかったようで積もり続けるということは なさそうだ。今はもう雨に変わっているし、夕方にはそれも止むそうだ。 明日以降もまだ寒さは続くようだけど、それでも確実に春が近づいているようだ。 まあとっくに桜は咲いて散りつつあるようだし


= COVID-19

_ 一週間ほどで感染者数が倍増して60万人を超えたようだ。勤務地のすぐ近くでも感染者が 出ているようだし、もう時間の問題かなあという感じがする。 オリンピックは延期が決定したようだ。夏のコミケもないらしい。 これから暖かくなってウィルスの活動が鈍ったりするんだろうか?

_ なおCOVID-19の統計情報を見やすく表示してくれていたサイトが、ある日からブラウザの 警告にひっかかるようになってしまった。フィッシングサイトなんだってさ。 乗っとられたのだろうか


= 最近のF#

_ 急ぎ作らなければいけない検査・分析用のものはF#で作っている。 目指すものを素早く作りつつ、それでいてやっつけではない、今後も 使いまわしてゆけるような構造を保ちつつ、ということを考えたときに、 知らないうちにF#がもっとも適切だと思える程度に馴染んできた。 問題はこれを他の人にメンテナンスしてもらおうと思うと 困難… ということだけど、まあ中身が分からなくても使えるような作りにするところまでを 目指しておくことで代用とすることに。

_ 馴染んだとはいえちょっと気になる部分が3つほどある。 まずはoptionを使いすぎなのではないか? という懸念。optionは、あってもなくてもよいが、 ないことがきちんと把握できて、途中でそれっぽい動きをさせずに上位まで矛盾なく引き渡すことが できるという点で、上記の「やっつけ」を避ける意味でもとても重要だ。と思っているんだが、 あちこちで使いすぎじゃないか?という気もしている。一定の基準で使ってゆかないと、 本来optionなんか使わないほうがよいケースでも使うようになってしまい、 気付いたらnullと大差ないではないか、なんてことになりかねない。

_ 次にRecordとDiscriminated Unionsを組み合わせて階層構造的なものを作りあげたときに、 その後のとりまわしが面倒くさく感じられてしまうという点。 構造の奥深くにあるものをいじりたいときに、いちいちパターンマッチングやらを駆使して 辿りつかなければいけないのは少々面倒に感じる。面倒といっても補助的な関数を作るなどして 工夫する余地はあるので、記述量はさほどでもないため、必要なことであれば別に問題なのだが、 実はもっとよい方法があるのではないか…? といった疑問がある。

_ 最後にモジュール分割をぜんぜんしていないという私側の問題がある。 関数の中に関数を作ったり、状態を保つためにclosureを使ったり…ということで でかい関数がたくさんできている。recordなどのtypeは共通だけど、処理そのものは 関数単位で独立しているので、モジュールを分けた方がメンテがしやすいように感じている。 が、まだやっていない。スクリプト (fsx) で書き始めるのがよくないのだろうか?そうでもないか


_ モジュール分割はとくに難しい話ではなかった。fsprojを自分でいじるのも、 順番が重要なのもあらかじめ知っていた話だし… open は module ごとにできるのはよいと思う。冒頭がopenだらけというのは なんかみっともない感じがするし、かといって毎回指定するのもうっとうしい

_ さらに構造をいろいろ見直し。ネストした関数はVSCodeだと型の情報を コメント的に表示してくれない。マウスカーソルを載せると表示されるので 推論できていないわけではないんだろうが、あえて出していないのかな。 あんまりネストした関数をたくさん作るもんじゃないよ、という教えなのかもしれない。


2020/03/30 (Mon)


= COVID-19

_ 志村けんが亡くなった。 喪失感もでかいが、それ以上にこの先こんな喪失体験をどのくらいしなければいけないのか、 という恐れの方が強いのは気のせいではないだろう。 会ったことがあるわけではないが、知っている人がCOVID-19に 感染して、かつ亡くなった、というのは私にとっては初めての経験だ。


= Formula 1 launches Virtual Grand Prix Series to replace postponed races

_ 年内のレース開催がなくなり、そのかわり公式ゲームでのレースになるらしい。 現役のレーサーやいろんな人が出場するレースになるようだ。これはすごい。


= 京成

_ 何ヶ月も乗っていなかったが先週から何度か利用するようになって、 車両が新しく綺麗になった、以外に、やたらと駅名表示やアナウンスに 「京成」がついているような。


= 最近のF#

_ いろんなフォーマットのファイルを解析しつつ、フォーマットは異なるが 伝送しているメッセージとしてはだいたい一緒、というようなケースで ちょっとpolymorphicなオブジェクトの存在が恋しくなってきた。 フォーマットは異なるけどキー項目は一緒、とか、とってくる場所は異なるけど 持っている値は一緒、とか、一方でこの値は一部のフォーマットにしか存在しない、 みたいなものをRecordとUnionだけでやるのはしんどく感じられる。




Zinnia (zinnia@risky-safety.org)
Back