_ 10月になった。今日は比較的気温が高いようだ。室温は27度まで上がっている。
_ PowerShellに馴染めないのは何度も書いている通りだ。いろいろ調べたり、コマンドレット1つで 実現できないのでいろいろ組み合わせたりする方法を考えたり… そして手に入るものは.NETのオブジェクトたちなわけなので、そこで使えるメンバーは 何だっけ、などといろいろ調べたり…ということをしていると F# Interactiveでいいやという気になってしまい結局身につかない。 が、これちょっと実行して結果教えてくれー みたいなことをするときにはfsxで渡すわけにもいかないのでやむなくPowerShellで書くことになり、 しかし身についていないのでなかなか書けずにキーとなってしまう。
_ Windows PowerShellにはISEという謎なIDEが存在しており、これがまたよいんだか よくないんだか…という感じだ。ISEはIntegrated Scripting Environment の略らしい。 とはいえ対話的にもスクリプティング的にも生のWindows PowerShellよりは書きやすいので がんばって使っている。
_ 今日も比較的暖かい。27度くらいまで上がったようだ。 日射しが強いので洗濯物もよく乾く。
_ スイッチつき電源タップを導入することによって手動のON/OFFは手軽にできるようになった。 今後センサー監視やらリモコンやらの仕事をさせたいと思っているが、立ち上げっぱなしというのは あまり精神衛生上よくないし、寝ている間はシャットダウンしておきたい。 しかしそうなると毎回OFF→ONが必要となり、たとえば寝ている間は シャットダウン→朝に何かを実行させる… ということがしたくなっても、 電源が入ってないのでムリーということに
_ まずRasPiはWakeOnLanはサポートしていないようだ。 RasPiの電源を制御するユニットというのはいくつか見つかったのだけど、 プログラマブルに電源ON/OFFできる製品というのはそれ自身が常時稼動している ユニットになるわけなので、きちんと時計を積んで内部でスケジュールが組めるようなものを 探そうとすると… そういうのはあるのかもしれないが高い。 まあRasPiにはRTCないのでそれを補いつつなにかすることができるものはあるようだ。
_ そんなことを考えながらいろいろ探してみたところ「スマートプラグ」というジャンルの 製品があることを知った。Amazon純正のものはAlexaとの連動しかできないけど スキルを使うことでスケジュール実行もできそうだし、 どうせ部屋にはEcho Inputが常時稼動しているわけなのでこれでいいのかもしれない… と思った。
_ 今日も比較的気温が高いようだ。図書館行ったり走ったりでのんびり過ごす予定
_ 面白かった。しかし三部作の第1作目らしいので色々とまだまだこれからなのだろう。
_ 面白かったんだけど、誰が読んでもものすごく面白いというほどとっつきがよい 感じもしない。私自身は面白いなあと思いつつ夢中になるというところまでは 至らず、3回 (夜) に分けて読み切った。読んでいる最中も退屈するわけではなく、 それでいて先が気になってしょうがない… というほどでもなく、ただ読み進めるのに 抵抗が少ない感じはすごいな、と思いながら読んでいた。 誰もが手放しで絶賛する感じでもない気がしていて、 その割には絶賛している記述ばかりが目につくのが不思議だなあと思いながら amazonのレビューを見てみたところ2〜3割は評価低めになっていた。 といっても最初から読む気のない者や 古典的名作に比肩する的な評価に気分を害している者がほとんどだった。
_ 私としてはハードSFとしての検証、というか、いつもの、 そんなうまいこといくんですかねー？ というやつを自力で解決する頭を持たないが、 それでもSFを読み慣れていないせいか、 光速を超えた通信なんてのは 理論的に可能だという前提で書かれているのかしら？ といった違和感を覚えた。 ただのSFならいいのかもしれんがハードSFというやつは物理現象に関しての 整合性をすごいがんばる系のSFなんじゃなかったっけ (この作品がハードSFなのかどうかは分かっていないのだけど
_ それはそれとして、「折りたたみ北京」の短編でも感じたけど、よくそんなこと 思いついてこれだけの物語に仕立て上げることができるもんだなあという感動がある。 2作目はすでに翻訳されているようだが… 英訳を読んだ方が早いのだろうか。 しかしSFだと文字通り単語がネックになりそうだ。なんだかんだで先が気になるし、 第1作(三体)の英訳は原著者自身の評価もかなり高いようだ。 訳者のblog。 訳者自身も作家でありつつ、英訳によって中国のSFを広く紹介するということを しているらしい。「折りたたみ北京」のアンソロジーもそういった活動のひとつなんだろう。読んだばかりであれば歯が立つかどうかも分かるだろうし、 The Three-Body Problem を読んでみるかな…Kindleなら500円だし
_ そうそうレビューの中に人名に常にルビがついていないので読みづらい/覚えられない ということを書いている人が数名いた。個人的にはあまり気にならなかった… 私にとって人名を覚えられないのは日本語であっても英語であっても同じで、とくに 英語の場合は書かれているものそのものにしか手がかりがなく、振仮名なんてものも 勿論ないし、イニシャルになったり愛称になったりといったさらに苛酷な環境なので、 それに比べれば漢字という手がかりのある人名はまだましな方だと思う。
_ 今日も気温はそこそこ高いようだ。室温は27度を超えている。 週後半はかなり寒くなるようだ。そして台風が近付いているらしい。
_ Webで回答できるようなのでそうした。前回もそうだったっけ…？
_ dynabookで回答しようとしたところuser agentのチェックにひっかかって進めなかった。 ブラウザを絞るならともかくOSを絞るというのはどういう意味があるんだろう？ あとQRコードから飛ぶ以外に検索サイトから「国勢調査 オンライン」で飛ぶように 指示が入っているが、誘導先がきちんと目的のサイトなのかを確認する手段が書かれていない。 絶対にフィッシングされないという自信があるのか？ まあかたり調査には相当するだろうけども
_ データサイエンスの指すものをよく理解できていないが、そのための能力が不足していることは 分かる。私の場合は、多変量解析の、その前段になるお膳立てを整えるところで 頭や手が馴染んでいないのでまず間違いないだろう。
_ 音響やら信号やらの解析も時系列データという点ではデータサイエンスの一種なんだろう (そうじゃなかったら恥ずかしいが本節ではその前提で話を継続する)。この手の 処理というやつは、以前も書いたけど昔ならRとかOctaveを使おうとしたと思う。 しかしどうもその手の環境に馴染み切らなかったのは、そのためだけに新しい言語や環境を 習得しなければいけない手間と、あとは性能に関して、悪化させるのは簡単だけど 改善させたくなった場合に出来ることがほとんどないんじゃないの？処理系任せなんだし… というような先入観があったからだ。別に性能が問題になるようなことをするほど たくさん使ったことがないくせに、そういうことばかりを気にしてしまうのだ。 同じような感覚はPrologにもあって、普段使い慣れた言語で同じようなことができるなら、 そっちの方がいいかなあ？という感覚が常にある。
_ で最近だとそのあたりはやはりPythonがいろいろ充実しているようだ。 NumPy、SciPy、Pandas (Rのデータフレームみたいなものらしい) あたりを使いつつ、 音響に特化した部分は 以前ちょっとだけ使ったlibROSAとか、 SoX (懐) のフロントエンドである GitHub - carlthome/python-audio-effects: Apply audio effects such as reverb and EQ directly to audio files or NumPy ndarrays.などを使ったり、 録音はPyAudioというのでやる記事が多い。PortAudioが必要。 このあたりはちょっと古いけどPythonで音響信号処理 - Qiitaに簡潔にまとまっている。
_ Pythonが充実しているのはよいとして、他はどうなのか？たとえばF#は？ まずグラフはFSharp.Chartingや XPlotというのがあるらしい。 後者はバックエンドにPlotlyを選ぶことができるようで、 そのXPlot.PlotlyはJupyterの中でも使えるようだ。 Dashというやつなのかな？ データフレーム的なものはDeedleというのがあるらしい。 FsLabというアプライアンスを入れると このあたりは大体入っているようだ。
_ Androidでやるという手もありそうだ。 ツールキットはいろいろ充実しているだろう…たぶん。 Visualizerなんてのもあるらしいし、 なにより騒音計的なアプリがオープンソースで出ていることが多い。
_ 動画を上げるときなどに音量の制限をかけるとかでよく出てくる単位がLUFSとかLKFSとか 呼ばれるもので、どうもこれらはただの音圧ではなく人間の聴感上の音量感 (ラウドネス) に よっていろいろ塩梅をよくしたものらしい。なので単位としては音圧のものと同じらしい。 つまり1LUFS/LKFSというのは1dBのことを指すようだ。
_ いいからスペクトログラムくらいさっさと出せよ、と、私の中の無闇に厳しい人格的なものが 前面に出てくるのでやる。試行錯誤するならJupyterだろう… しかしブラウザでいじるより Visual Studio Codeの方がいいかなあ〜 と思いいじってみたのだが、いざスペクトログラムを 出そうとしたらあほみたいに遅い。20秒くらいかかる。 いくらなんでもこんなに遅いのは何かおかしい気がしつつ、しかしこの性能ではとても試行錯誤どころではないなあと思いながら、 ふとブラウザの方で実行してみたら数百msecで結果が出てきた。あらあら…
_ SoXというと昔からいろんなタイミングでたまに登場し そのたびに懐しくなる。 1年半前にも懐かしがっていた。 だいたいフォーマット変換とか、せいぜい サンプリングレート変換とかステレオをモノラルにするとか、 という程度にしか使っていなかったが、よくよく見てみると色々なことができるようだ。
_ で昨日リンクしたGitHub - carlthome/python-audio-effects: Apply audio effects such as reverb and EQ directly to audio files or NumPy ndarrays.は、 そのSoXのフロントエンドという説明になっている。 コードを読んでみると本当にフロントエンドという感じで、コマンドラインオプションを組み立てて SoXを呼ぶというものらしい。まあJupyterの中で使うことを考えると これはこれで悪くないかもしれない。numpy.ndarrayのまま渡すこともできるし
_ STFTも入っているし最初からこれを使っていればよかったのではないか感がある。 そしてしばらく使った後にimportがうまくいかなくなってしまった。 importからいつまで経っても (といっても1時間くらいしか放置してないけど) 返ってこない。 issueを見てみたところそのものずばりの症状が あった。 どうもnumbaというやつのキャッシュディレクトリに権限がないとWindowsの場合には こういう動きになってしまうらしい。アドバイスの通りNUMBA_CACHE_DIRをいじって回避
_ 今日は雨がちで気温も低め
_ 音響のはなしのつづき。検証やらはJupyterでやるのは変わらんが、計測に関しては Androidの力も借りておくか〜という気になってきた。Androidのねたがない状態が 続いていていつまでもKotlinともども手に馴染まない、ので、もうちょっと触る機会を 増やしてゆこうと思う
_ 計測対象のデバイスにはMsgPackをベースにしたデバッグの口を用意していたので、 これを活用して、Androidから仮説に基づいた音源を渡し、対象のデバイスで再生、 そしてそれをAndroidで計測して、フィードバックして… ということをしたいと思った。 音源自体の加工は、Androidの中でやってもよいし、別の登場人物としてPCを用意してそっちで Pythonを操ってどうにかする…などが考えられる。
_ まあともあれその足まわりを整えた。まず対象のデバイスのコマンドを拡張して 音源の再生をできるようにして、すでにあるPCのクライアントを拡張して正常に動くことを 確認した後、Android側に同じコマンドを実装してデバイスにUDPで送りつけて… 無事Android.os.NetworkOnMainThreadExceptionが出ることを確認… UDPで投げ捨てるだけなのだから見逃してほしいもんだが、Manifestいじってまで 通したいとは思わないのでやむなく別スレッドにする。 今でもAsyncTaskを使うのかな？ と調べてみるとKotlinにはCoroutineがあるので そっちで実装したほうが楽そうだった。のでそうしたところ無事に遠隔で音を鳴らすことが できるようになった。
_ 主にAndroid+Kotlin側に慣れないため多少時間がかかった。さっさと作り上げるなら Android側は土管にしておいてPCと計測対象デバイスの仲介をしてやればよいのだが、 それだとAndroid+Kotlinでやることがかなり少なくなってしまい あまり訓練にならないかもしれない。むずかしいね
_ そういえば.NETの次期UIフレームワークMAUIというやつを最近ちらほら見る。 Androidのアプリ開発でJavaやらKotlinやらをやむなく使っているものの、 何年も前からXamarinががんばっているようだし、それが.NET 5でさらに いろいろ整理されるみたいなのに対してろくに触ったことがないのはよくない気がしてきた。 XamarinはAndroidで使うにはVMとの相互運用をつねに意識していなければいけないようで 無理に使いたいという気がしないというか、それならKotlinでいいか…という気がどうしてもしてしまうのだけど
_ 現状F#でクロスプラットフォームのアプリを書くには Fabulousというのが使えるらしい。MVU architectureということなので 先日やったElmishとおなじかな…と、F#が使えるねたを探していてもしかたがない
_ 台風は本州にあまり近付けなかったようで、雨も風もたいしたことなかった。 今年はほとんど台風の存在感を感じることがないな
_ 対話的にやるならfsiを中心にすればよいのだろう。 今回はどちらかというとevalのようなことがしたい。
_ 先日買ったリモコンユニットを用いたアプリを作ってゆきたい。RasPiに接続して 使おうとしており、試行錯誤をRasPiだけでやるのは遅くて大変なのでできればやりたくない。 なので最低限の待ち受けだけをRasPiでやらせておいて、他のPCから来た何らかの指示を 中継させることができれば、細かい作りこみは他のPCでやることができるし、 形がまとまってきたらRasPiにデプロイして稼動…なんてことができるように思う。
_ ひとまずリモコンの信号出したり、寝たり、繰り返したりといった原始的なコマンドを F#内でEDSL的に書けるようにした。複数の信号を組み合わせて目的の機能を実現することに なるわけなので、こういうのを書きやすくするためのDSLがあるのはよいことだし、 それを最終的には外出しにしたい。 しかしEDSLなので外に出すときにそのまんまというわけにはいかない。 それっぽい言語にマッピングするとなると、せっかくEDSLで気軽に書けていたはずなのに 急に泥臭い感じがしてしまう。
_ じゃあ元のコードをそのまま実行できるようにしようか…と思って調べてみると、 CodeDOMを用いたやりかたばかりが出てくる。それじゃC#のときと変わらん
_ ……sshでコマンド直接叩いてしまえばそれまでという気がとてもしてきた
_ 健康診断の待ち時間に読むために借りた。 以前から読みたいと思っていたものだったが、きっかけは何だったか… たしか中曽根康弘が昨年末に亡くなったときに贈従一位になったというニュースを見て、 位階について眺めて、生前に正一位になった数少ない人物のひとりに 三条実美の名があって、もちろんその名前はよく知っているが、これまで 見聞きした資料や小説などではあまり存在感のある人ではなかったので、 どんな感じの人なんだろうねえと興味を持った。のでこの本を読みたくなった、 のだと思う。
_ 10代の頃は歴史ものといえば歴史小説で、この本のようないわゆる 「中公新書の緑色のやつ」はほとんど読んだことがなかった。この本の著者は 1967年生まれなので私よりも8歳年上だ。こういう年代の人達がその 中公新書の緑色のやつを執筆する時代になったんだなあ〜と思った。
_ 肝心の中身だが… やはりこの時代の動きの激しさはすさまじく、どの切口から 読んでも面白い。若い頃はやはり接してきた小説の影響で、幕府寄りの人達や 公家に対して関心が薄かったし、今に続く動きかどうかという点で 「大攘夷」ではない狭義の？攘夷に共感を抱くことは難しかったが、 そういう意味では三条といえば私にとってその不利な要素を兼ね備えている存在だ。 本書ではそんな三条の立ち位置や信条、そしてその「影の薄さ」について 著者の考察を交えつつ描き出していてよかった。 三条自身のほか、 孝明天皇 (「最後の将軍」では幕府の理解者であるという描かれかただったが、 本書では幕府による攘夷を強く望むあまり複数の場面でハレーションを起こしている 人物として描かれている) とか、 島津久光 (維新後の体制に不満があった、というのは当然想像可能だが、この本では もっと積極的に元家臣や新政府を攻撃する様子が描かれており、 なんだかアンシャン・レジームが実体化したような人物に見えている) など、 人物像が逆転・変化したケースが多かった。
_ 筒美京平さんといえば70年〜90年代にヒット曲を連発した作曲家で、 そのヒット曲というのはもちろん商業的にもそうなんだろうけど、 私に対してもそうであって、つまり好きな曲の多くを筒美さんが作曲されていた。 私が生まれる前や、物心つく前の曲を10代後半に聞くようになって、 いいなと思う曲の多くを筒美さんが作曲していたり、小学〜高校くらいに よく親しんだ曲の中に、ああこれも筒美さんの作曲だったのか、と後になって 気付くなど、私の中で再発見を繰り返している。
_ あまり表に出てこない方なので、わずかなインタビュー記事の抜粋を読んだことが ある程度で、私の中では大作曲家という虚像が崩れないまま尊敬の対象となっている。
_ 立て続けにショックなニュースが。 まつもとさんは闘病生活を長く続けていたことは知っていたが、 近年は心臓も弱っていたそうだ。
_ ZHTに書いたことはなかったと思うが、 「きまぐれオレンジ☆ロード」は、私にとって理由はよくわからないけどとても 好きな作品で、高校の一時期はこの作品に自分の生活を支配されていたといっても よいくらいだ。リアルタイムの連載を見ていたわけではなく、高校の近くの 古本屋で全18巻だったかをまとめて売られていたのをなんとなく買って、 ものすごく面白い…というほどの興奮はないのになぜか大好きで、 繰り返し読みたくなる魅力があった。
_ そしてそれ以上に私の生活を支配したのはアニメの方だった。テレビ放映はとっくに 終わっていたので、レンタルビデオでどうにかそれを見たいと思って、 高校…2年？3年の夏休みに横須賀市じゅうのレンタルビデオ店を探しまわったのを 覚えている。タウンページのレンタルビデオ店のカテゴリーに並んでいる店を、 自転車で何日もかけてまわった。たしか30店くらいあっただろうか。半月くらいかけて まわったと思う。何でそんな情熱を注いだのか自分でもよくわからないのだが、 それだけまわっても結局見つけることはできなかった。がっかりしたのか、 そうでもなかったのか、は、よく覚えていない。その半年〜数年後、 自宅の近くに新しく出来たレンタルビデオ店であっけなく全巻借りることができて 拍子抜けしたことは覚えている。 アニメも漫画も、なぜそこまでのめりこんだのか分からないが、なぜか好きだった。 雰囲気が好きだったのだろう。その世界を覗きこむだけで幸せというような感覚。
_ その後の作品、「せさみ☆すとりーと」は、途中まで読んだ。 「きまぐれオレンジ☆ロード」が 中学生〜高校生がメインだったのに対し、 せさみ☆すとりーとはもうちょっと上の、浪人〜大学生活のひとたちがメイン だった…と思う。途中で読まなくなったのか、連載が中絶したのが先なのかは よく覚えていない。いくつかの新興宗教の筆頭者を揶揄するようなシーンがあったのは 今でも覚えている。
_ Wikipediaによると テレビ放映があったのは1988年3月までだったらしい。 となると、私がレンタルビデオ店をはしごしていた頃はまだソフト化されていなかったか、 レンタルにまわっていなかったのかもしれない。 OVAや劇場版もあったようだ。知らなかった。特に関心を示していないところを見ると、 熱が覚めたのかもしれない。ただ、それにしても生活を支配されると表現してしまうほど のめりこんだ作品は他に思いつかないので、私にとっては今でも特別なものだ。
_ 筒美さん→C-C-B (多くの曲を筒美さんが作曲していたらしい)→そういえば ヨープレイトのCMの曲をやっていたらしい… と連想して 辿りついた。私の記憶に残っている曲はC-C-Bのものではなく、 オスカルというアルゼンチンの歌手が作曲・歌っている「異国」という曲らしい。 10年以上前の疑問が解消した。 10秒そこそこの短かいメロディでここまで心を掴まれて長く記憶に残るというのは すごいことだと思う。
_ 高校の頃に何かのきっかけで「きかんしゃトーマス」の話題になり、 その会話に入っていたクラスメートの一人が「きかんしゃ やえもん」 というものがある、ということを言い出して、そんなものはない⇔いやある、みたいな 言い合いになったことがある。で結局あるともないとも結論が出ないまま 卒業して、それっきりクラスメートと会うこともないので、きかんしゃ やえもんの 存在は私の中では宙に浮いたままだった。 が、その独特なネーミングセンスに魅了されたので何かの拍子にその名前を 思い出すことがあった。
_ 私の高校時代はそんな呑気な論争で半年や1年はひっぱることができたのだけど、 今の御時世であればこんな言い合いは分単位で 解決してしまうのだ。
_ 住居のあるマンションの足場解体が始まったようだ。 なんだかんだで半月余計にかかったような、しかし私の部屋の窓のある場所は 建物の裏側に相当するのか、常日頃からうるさいとか水が降ってくるといったことは なかったようだが…
_ だいぶ涼しい。
_ 昨晩は吐き気と腹痛でえらいことになった。最初は食べすぎかと思ったんだが、 吐き気もわりと執拗だし、腹痛も出はじめたので食中毒だったのかもしれない。 昨日の夕方に食べたジンギスカンだろうか。食中毒かどうかは別として 大変うまかったのでまた行きたい。
_ RasPiでリモコンやったりセンサーつけてどうにかしたり、そのためのUIを用意したり… という一連の取組を統合してリポジトリを作成した。 名前は表題の通りだ。Smartでは謙遜しすぎだろうと思ったのでこのようになった。
_ SAFE Dojoを修了したばかりなのでじゃあその流れで… ということでSAFE.Templateで 開発をはじめる。クライアントとサーバ間の通信があほみたいに簡単なのは、 Fable.Remotingというものを使っているかららしい。 それはそれでよいんだが、ただGETするだけ、とか、RESTっぽく… と考えると Fable.Remotingじゃないほうがありがたい。
_ SaturnやGiraffeのドキュメントをいろいろ見てまわって、 複数のルータを併用することができることがわかったので、Fable.Remotingのやつの 他にシンプルなルータを用意することで期待通りGETするだけという動きを 実現することができた。 RasPiローカルで動いているときはCOMやI2Cに直接何かをするけど、それ以外のときには ここで準備した簡易IFでRasPiに飛ばすということができるようになった。 なので普段は別のマシンで開発しておいて、変更がひと通り済んだら RasPiにpullして… というような開発フローをとることができるようになった。 全部RasPiで開発するのは少々ストレスなのでよかった。
_ 今回作りたいアプリはあんまりクライアントと サーバがドラスティックになんかするわけではないので SAFEはちょっと大袈裟かもしれない…シンプルな何かをしようと思うと、 SAFEのテンプレートが何をやっているのかをひとつひとつ解体していって、 だんだんSAFEっぽい何かを除去してゆくことになっている気がしてならない
_ ジョンが一週間ほど里帰りをすることになった。もうすぐ事務所にやってくる。 簡単な片付けと、側面という側面にトイレシートの貼付、などは昨日のうちに 済ませてある。
_ ジョンとはだいたい半年に1回くらいの間隔で会えている。 前回は2月。 ジョンももう10歳を超えており あと何回会えるのだろうか…などと考えてしまう年頃だ。 お子様ともうまくやっているようで、 落とした離乳食を食べてかなり太ってしまっているらしい。一週間 たくさん運動をしてまた引き締まるだろうか。
_ ジョンやって来た。太ったせいか首がないように見える。 顔の大きさは変わらないので、長い胴体に直接頭がついたような…不思議な体型になっている。 これは散歩やらを沢山やって引締めないといけないだろう… 幸いジョンはすぐ結果に出るので一週間でも十分に効果があるだろう
_ 今日は雨。気温も低い。 ジョンは昨日の夕方？あたりに左前足をかばうような歩きかたになっており、 どっか痛いのか？ と心配した。触っても痛そうにしないし、ジャンプしてベッドに乗ったり 降りたりも普通にできているし、おやつや御飯のときにぐるぐる回っている様子を見ると 本当に痛いのか？という気がしてくる。そして今日は普通に歩いている。 なんだったんだ？
_ 会社のプロダクトはWindowsで動くことが前提のものが多い。といって 他のOSではまったく動かないかというと、.NETとSQL Serverが動けばだいたいなんとかなる。 以前USBデバイスが絡むWindowsのプロダクトをmonoで動かした際はとくに問題らしい問題もなく 動いてくれたし、SQL Serverも今ではLinuxで動くので、それらをうまいことやれば VagrantなりDockerなりで使わせることができそうだと思う。
_ VMでやるとすると… 社内ではWindows Sandboxを使ったりWSLを入れたきり使ってなかったりという人口が多いので VirtualBoxよりもHyper-Vで構築したほうがいいのかもしれない。 Dockerのスキルが一定量以上あればこれで配布した方が圧倒的に楽なのだが… ひとまず自分用に作ってみて、レクチャーする手間に見合うようなら広めてみるか… そもそも動くかどうかも分からない状態だが
_ 移植というよりは、Windowsで動かしているものをそのままLinuxで動かしているというような 形態らしい。 Drawbridgeという技術の応用なのだとか。
_ ジョンは土曜の朝に帰ることが決まったようだ。 今は預かり時代からジョンのケアをしてくれているサロンにシャンプーをしてもらっている。 うちに来る直前にシャンプーしてもらっていたのか、来てすぐはわりといい香りをしていたもんだが、 日が進むにつれだいぶ色々な匂いがついてきていたので丁度よいだろう。 そして今晩〜明日にかけては雨がちらしいのであまり散歩などもできない。
_ 再代入は <- なのはもちろん理解しているがやはりイコールで書いてしまうケースが多い。 そして、Base Common Library を積極的に使わなければいけない場面では プロパティに値をセットしたいときに <- を使わなければいけない。のだが どうも = を使ってしまってセットできていない〜〜 というケースが続発してしまう。 評価結果 (true/false) を捨てていることに対する警告が出てもよい気がするんだが… どうも出ないようだ。戻り値捨ててるときは警告出るのだが…
_ 単に式の値を捨ててるのを警告にするだけだと let とかもひっかかってしまうので いちいち ignore しなきゃだめか… さすがにそれはしんどいな
_ … fsi の中でやっていたからか。そういえばこのようなとらぶるを経験したのは プログラムを書く前にfsiでお試ししているときだけかもしれない。 fsiでも、関数の中とか、 do の中で記述すればきちんと警告してくれるらしい 実際に試してみたら確かに警告が出た。
_ mono動かして対象プロダクトがちゃんと動くところまで試してみるか… と久しぶりにHyper-Vの中で飼っているUbuntuを起動したところIPが生えていないという 以前の問題がそのまま残っていた。 何も対策していないんだから当然かもしれんが… そして世間ではこの手の情報がなにか 集まっていないか？ と思ったが以前見たときとほとんど変わっておらん
_ 今日は雨。ジョンの散歩はむりそうだ。
_ ここ2週間くらいかなり最低気温が低く、朝方や夜は何か上着を羽織りたくなる。 涼しいというよりは、はっきりと寒いと感じられるレベルだ。まあ10月も中旬を過ぎたのだから そのくらいの陽気になっても当然なんだろうが、今年はあまり外出もしていないので季節の 移りかわりがよくわからない。
_ 社内のプロダクトをmonoで動かして最終的にコンテナ化できればいいかなーなどと思いつつ、 一方で現状取りまわしを悪くする原因はあまり多くなく、ひとつはフルパスで指定している 箇所があること、そしてもうひとつはやはりSQL Server背負っているということで、 前者はまあ工夫次第でどうにかなるし、後者は… 単純に評価用の環境を作るためにわざわざ あれこれ構築するのは面倒だし共存も大変。SQLiteあたりで済ませられないかしら？
_ System.Data.SqlClient を使っている箇所をいろいろ直せば出来るようになるのは 当然分かっているものの、System.Data.SqlClient を使いつつバックエンドはSQLiteになります みたいなのだとなおよいのだが。もともとSystem.Data.SqlClient ならではのことは ほとんどやっていないし、ODBCならもうちょっとやりようがあったのかもしれないが…
_ MediaRecorderというやつと、AudioRecordというやつがあるらしい。 リアルタイムで録音しつつそのデータを取得するという使い方だと 後者の方が合っているように見える。
_ Visualizerというやつのできることがいまひとつ不明というか、 内部で効率のよいFFTを積んでいるのだがよいという程度かしら…？ FFTくらいなら外で準備できるわけだし、別にいいかという感がある。
_ 2ヶ月前にも交通系で事象としてはよく似ているものが起きている。
_ いずれもプリペイドなので、二重に引き去りをするということが 起きうるのは「2回書いた」ときだけのはずだ。しかも、 ただ単に同じものを2回書いただけであれば、ランダムなら同じ残高が上書きされるだけだし、 パースならなんとかID(名称失念)が同じものは無視されるだけだし、 今回は関係ないけどサイクリックはまったく同一のブロックデータは連続して書けないようになっているので、 同じコマンドが二重に飛んだだけでは引き去りが二重に発生することはない。 なので2回の引き去り処理をした場合しかない…わけだが、これが 多くのプリペイドで発生しているというのはどういう状況なのかなあ。 処理未了に関連するシーケンスくらいしか思いつかないが、それにしては件数があまり 多くないような気もする。
_ あと、影響があったかどうかを確認するために「カードIDによる判定ページ」というものが 存在するのも違和感がある。まあプリペイドなのでいいのかもしれないが、判定ができるということは カードIDを保持していて、かつ今回問題があった期間 (2011年〜) ずっと保持しつづけていた ということになるわけで、そんな物騒な仕様でいいんだっけ…？ プリペイドの 要件は詳しくないので知ったかぶりはできないけど… あとそもそも 今残っているデータで該当するものが判別できるというのも、運よくそうなっていたのか どうなのかは気になるところだ。残っているデータがシーケンスを再現できるほど 詳細なものだということはあんまりないような気がするし (完全に想像)
_ …などと書いていたが、TMNの端末は今となってはかなり広く普及しているので、 私も利用者として影響が発生している可能性がゼロではないということに気付いた。 まあしょうがないか… いくら判別可能といってもやらかした会社にIDを渡すことの 危険性が分からないので渡したくないし…
_ ジョンが帰還していった。短かい間だったがジョンはあいかわらずジョンだった。 昨日はなぜか分からんが情緒不安定だったけど今朝は落ち着いていてよかった。
_ 8月分の電気代の請求が来た。8月は悪夢のような暑さが連続していたので エアコンはほぼ付けっぱなしだったのでさぞ高くなるだろうと警戒していた。 で、結果は6000円しない程度だったのでそこまで壮絶というわけではなかった。
_ 室内の蛍光灯のリモコンの効きが悪くなってきてしまい ひとまずリモコンの機能をさっさと組み上げてしまうことにした。 単発での操作はボタン押してそれに反応するだけなので特に難しくはない。
_ その後、他のリモコン機器についても実装を進め、テレビ(Bravia)、HDMIセレクタ、 DC扇風機、エアコンのボタンを実装した。 BraviaについてはHDMIの系統切り替えを連続で実行できるように 先日試作したやつを組み込んでみた。 これでリモコンの↓↑を駆使した複数ストロークの操作をボタンひとつでできるようになった。 なので元々のリモコンよりすでに便利になっている。本物のリモコンを 使わないで生活できるかしばらく様子を見てみようと思う。
_ サーバ側は、Saturnのドキュメントだけを読んでもいろいろ分からないところが 多く、よくよく読み進めてみるとGiraffeやASP.NET Coreの部分がある程度 理解できていることが前提になっているような感じだった。 Giraffeを作ったひとが製作の動機について Functional ASP.NET Core - Dusted Codesという記事にまとめている。 これはわりと分かりやすい気がする。
_ リモコン部分はまだまだ細かい制御が必要なのと、 せっかくFable.Remotingを使っているのにやりとりしているデータが文字列ひとつみたいな無能な感じなので、 もう少しサーバ側の型をきちんと使ってやりとりできるようにしようかなと思う。 あとbme280のデータをJSONでとれるようにしたので、 ではType Providerを使ってみるか…とやってみた。もちろんサーバ側は 問題ないのだが…同じものをクライアントで使いたいので、じゃあShareの paket.referencesに登録すればいいのかな… と思ったらpaket.referencesは ServerとClientにしかない。ということは同じパッケージを共有することは できないのかしら？FAQを読んでみると、 なるほど、 クライアント側は最終的にJavascriptにトランスパイルされるわけなので それに対応したものじゃないと使えないらしい。すっかり忘れていた。 FSharp.Dataを使えないと死ぬわけではないので別に使えないなら 使えないで構わないというか、サーバとクライアントで同じデータ構造が 使えなきゃ意味がないので片方でしか使えないなら使わないほうがいいかなあという 気がする。なおFSharp.Dataがクライアントで使えないかどうかは不明なままだが
_ 音まわりの話を取り入れるためにいくつか本を読んでいた。 どうも執筆者に偏りがあるのか、 音響関係というと騒音対策に結びつく話が多いみたいだ。
_ 「音と振動の科学」という本の冒頭でギターの音が出る 原理の話をしており目から鱗だった。 弦の振動をサウンドホール経由で響板内で反響させて… というふうに思いがちだけど それはよくある誤解で、実際は弦の振動をブリッジが受けてそれによって響板が 振動して、筐体内で反響が起きるということらしい。そしてサウンドホールは バスレフの穴みたいな役割になるそうだ。知らなんだ… 正確にはあちこちの本で そう書いていたのかもしれないが理解する力がなかったのだろう。
_ 以前ウクレレの音を小さくする試みを何度かやった (1、 2、 3) ときは、なんとなくサウンドホールを 塞げばいいんでしょくらいの発想でしかなく、ウクレレがどういう原理で 大きな音を出しているのかをまったく考えていなかった。 おそらく単にニードルフェルトを詰めるだけでは、筐体内の反響を防いで バスレフの効果をなくすことはできても、響板自体の振動を小さくすることは ほとんどできていない (裏面に耳を近づけるとけっこう大きな音が聞こえるのは そのせいだったのかな) ので、もっと振動そのものを防ぐことができるくらいに 充填すればまた話は変わるのかもしれない… などといろいろ考えさせられた。
_ 散髪をした。長いとなかなか乾かないしシャンプーリンスも多く必要になるので あまりうれしいことがない。
_ 久しぶりに水元公園に来てみた。金町に至る経路、ならびに水元公園に至る経路、 そして水元公園そのものについて、いずれも 大きな変化はほとんどなく、今日からでも地元民として馴染めそうなくらいだった。 なので懐しいという感じもあまりない。1年くらい来てないはずなのだが
_ 気温も高くなかったので快適に走ることができた。歩きも含めて12km弱。 普段より1.5倍程度の距離なのにわりと疲れた。そして速度を落としていると けっこう肌寒さを感じる陽気だったのでそれも体力を消耗する 原因だったのかもしれない。そして金町湯は10月一杯は改装工事らしくお休みだった。 つくづく縁がない
_ なんか考えごとをしながら走っていたせいか、普段のコースと比べれば オープンワールドと言っても差し支えない水元公園の自然を楽しむことがあまり できなかったように思う。 考えごと…というほどではないが、気が散る要因としては 走り終わった後に着替えて電車で帰らなきゃいけないので、 都合よく着替える場所が空いていればいいのだが…というようなものも含まれている。 金町に住んでいた頃はそんな心配も無用だったわけなので、 いかに恵まれた環境だったのかを今更のように思い知らされる
_ Thincacloudも…？ Thin client式の決済端末としてはトップ2と思われる TMNとThincacloudで同じように見える、長期間に渡って発生していた障害が 同時期に発覚するというのはなんだか因縁めいていて不気味だ。