_ 夜中にスマホのバイブが震え続けていたような気がちょっとして、 その前後に地震があったような気もちょっとした。 朝起きたらスマホが再起動されていたので、ではあのバイブはひとりでに 再起動時したときのやつなのだろうか？ (地震か？と思ったのは忘れていた) と思いながら ニュースを眺めていたらどうやら地震があって緊急地震速報も出ていたらしい。 会社に来てみたら会社スマホが緊急地震速報の画面のままだった。
_ このスマホは緊急地震速報に無反応というわけではなかった気がするが、 あの寿命が縮まりそうな音なんかはしなかったように思う。 なので緊急地震速報に対して何かしようとして再起動かかってしまったのだろうか？ あわわ地震だあわわ(再起動)といったような…
_ 自席でのテレビ会議用に以前買ったマイクは無指向性なので周囲の音を積極的に拾ってしまう。 とても小さくて軽いので外音取り込みには便利なんだけど
_ 打ち合わせのたびにあれこれ持って会議室に行くのもだるいので、単一指向性のマイクが 欲しくなってきた。ピンマイク的なものの他にも、いかにもマイクといった形状のものがあったり、 「太陽にほえろ」で山さんが使っているような (記憶曖昧) 卓上式無線機みたいな形状をしたものがあったりする。いかにもマイクといった形状のものは 規格に合ったものであればマイクスタンドを交換したり、アームつけたりもできるようだ。
_ でアームを取り付ければ必要なときに口の近くに持ってゆけるので便利かな… と思いながら ゲーム実況の人とかが使っている様子を見てみたところ、液晶アームほど位置・角度の 自由度がなさそうに見えるのと、やっぱり存在感がでかい。ブースみたいなスペースを 占めているならありかもしれんが…
_ 小さな三脚みたいなスタンドをつけた状態のものは机の手前に置いて使うことを 想定しているように見える。幸い私はデュアルキーボード派で、 ハの字に置いたキーボードの手前に三角形のスペースがつねにある状態なので そのスペースに物を置くことはまったく問題ない。それに単一指向性の特性が よく言われる cardioid (心臓) の形の通りであれば、スタンドの後ろにあるキーボードの音は あまり拾わない…なずなので、そういう点でも都合がいいだろう。 そのあたりのものを探してみるか…
_ コストコでキャリーバッグセット的なものを買って、 持ち手部分にひっかけることができる‥ キャリーオンバッグというのかな？ その部分を 普段の仕事用のかばんに使っており、それが2〜3年経過してだいぶくたびれたので 新しいものを買いたい。
_ そもそもそのかばんは、キャリーオンバッグなのでほとんど容積がなく、 ノートPCや書類などを入れると他にあまり物を入れることができない(といっても ノートPC2台入れて運んでいたこともあるのであほみたいに小さいわけではない。 ただそんなことをしていたので寿命が縮まったのかもしれないが)。 なのでサブでトートバッグが必須になっている。まあ重さが分散できるという点をとれば 悪くはないのかもしれんが、歩く機会が増えている最近ではあまりバランスよく 持ち運びができている感じがしない。
_ 米沢にいた頃は、今で言うところの3wayバッグというやつを使っており (当時もそう言っていたかもしれん)、 肩かけや手提げで使うことができつつ、リュックとしても使えて大変重宝していた。 やはり重たいものを運ぶときなどはリュックの方が楽だ。歩くときにもリュックの方がいい… 気がする。ただどうしても背中が蒸れるので、そこまで背負うことにこだわっても しょうがないのかもしれない。
_ 3wayというとTUMIというメーカーが有名らしい。 私は持ち物はバッグインバッグとかファスナーつきポーチみたいなもので 小分けにしたいほうなので、あまりかばんそのものにポケットがいっぱいあるとか、 そういったものは求めていない。仕事のときと近場のおでかけのときでは 使うかばんが異なりつつも、持って運ぶものは同じだったり違ったりするので、 その小分けにした範囲で移してゆけば忘れものも減らすことができてよい。 TUMIのものはけっこう間仕切りがしっかりしていてポケットが多め、という感じのようで 私の求めるものとは少し違う。
_ AS2OV という (2のところはSが裏返しになったもののようだが表記上こうなるらしい) ところの3wayバッグは、良くも悪くも背負うのがメインという感じで Deuter みたいな蒸れを防ぐ形状をしているなどをしている一方、 背負わないときに背負う部分がかなり目立つような収納になってしまうようだ。
_ MYSTERY RANCHというところのやつは、フロントのジップポケットの形状が独特だ。 カニの腹みたいだ (……) それ以外はかなりシンプルで好感が持てる。 ブリーフケースなのでそんなに容量はない (14L) が、よくある「マチを広げると容積アップ」が できるようで、そうすると21Lまで広げられるらしい。それはそれでよい…が こういうものは私の場合だいたい広げたまま使うことになるので、耐久性が 少し心配。
_ USB接続のやつはいろいろ気をつかわなくていいのかもしれんが、USBインターフェース部分が 価格に響いてくるわけだしちょっと割高。
_ マイクにもいろいろ原理があるようで、ダイナミックマイクというのは いわゆるスピーカーの逆の働きをするやつなのに対し、コンデンサマイクというのは、 なんかコンデンサを使ったマイクらしい (ひどい説明) 感度がよりよかったりするかわりに 電源供給が必要らしい。ミキサーによくある48Vみたいなスイッチはそのためのものだったのか。
_ マイクつなげるときの3ピン？のDIN的な端子はXLRというらしい。キャノン端子ともいうそうだ。
_ Who's in Charge?を読んだ後に 翻訳を読んだら「創発」という用語が出てきて、 あれこんな表現原著にあったっけ？ と思い、先日再度原著を読みなおしたところ emergenceの訳語が「創発」らしいということをようやく理解した。 emergenceという単語から連想するのは、表出する、発現する、みたいな、感じだったので 何らかの現象を示す物理用語的なものだという理解ができていなかった。 そもそも「創発」という日本語にされても理解できなかったんだけど…
_ Exotic Sandsというらしい。 これは面白い。フローティングペン好きの妻にも聞いてみたところよさそうという感じらしい。
_ 今週はあまり雨が降らなそうなので、2足買った靴のうちのもう1足、 半額のほうを使ってみた。これは今まで履いていたものと形状も近く そして軽いので足を攻撃されることもなく履き心地はとてもよい。
_ Who's in Charge? の再読も終わったので移動中もこっちを読み進めることにした。 で読み上げをさせてみたんだが… どうも途中で読み上げを止めてしまうことが多くて なかなか読み進められない。そもそも本文をスクロールさせるのが大変にむずかしい。 15分ほどの移動でそんなことでまごまごしていたらまったく読み進められないので、 読み上げはあきらめてただ読むだけにした。
_ 日付変わる前にフトンに入り3時くらいにはっきりと目が覚めてしまい、 7時前まで眠れなかった。ずっとフトンの中にいたわけではなく、どうせ 眠れんと思ったので起きていろいろ家事などをしていたのだが…
_ ……先日Ubuntu 19.10 に上げたサーバが謎の再起動を繰り返すようになってしまった。 30分かそのくらい経過すると再起動がかかり、起動はするもののまたしばらくすると再起動… という繰り返しだ。まじかよ
_ JavaはInputStreamとOutputStreamが分かれているので、 いったんメモリにコピーしといて再度InputStreamとして使って…などとしたかったら、 ByteArrayOutputStreamつくって、copyTo して、toByteArray したやつを ByteArrayInputStream つくって… とするしかないのかな。なんとかならんもんかな。 まあin/out両方できるようなStreamでrewind忘れて数日停滞する人間に言われたくないだろうが…
_ ... ZipException (invalid compression method) で落ちるzipファイルがある。 Methodの番号は9… あれjava.util.zipもdeflate64サポートしてないのか… Apache CommonsのCompressならサポートしているらしい。うーん
_ さてpcapngを読む… pkts.ioはどうやらpcapngをサポートしていないようだ。 Pcap4Jは、読めるようだけどlibpcapのwrapperなので入力をStreamで、というわけにはいかないようだ。 うーん‥。
_ まあpcapngなんてたいして複雑なフォーマットでもないので、 Ethernetフレームを露出させるまでは自力でやってもそれまでかもしれない。 ただEthernetフレーム以降はやっぱり解析してほしい気がしないでもない。 それはそれで、たいして複雑なもんではないけど、けっこう手間がかかる。
_ あとは、Memory Mapped Fileにしてlibpcapベースのものと連携する… というのが あるだろうか？あまり気がすすまないが… キャプチャをとったり制御したい、というのであれば ともかく、単にpcap/pcapngをparseするだけでJNIやらJNAやらを駆使してなんかする、 というのは想像するだけでしんどそうな感じがする。
_ 向こう数日はほとんど触ることができないのでSubversionにつっこんでおくことにする。 どれを上げてどれを上げないべきか…？ というのがよくわからん。 ドキュメントがあるのはいいんだが、 .gradleは？buildは？といったあきらかに不要と思われるものがカバーされていないなど ドキュメントの前提になる知識がありそう。 GitHubに上がっているのを人力ワイルドカードで選んでゆくことになるだろうか。
_ 不調なマシンの件、memtest86+を二晩連続でかけたが特に問題ないようだ。 ということはメモリとしても問題なさそうで、かつハードウェア的な問題で一定時間経過したら 再起動がかかってしまう、というわけでもなさそうだ。
_ しばらく落ち着いて席にいる時間がとれないような感じだったので放置していた memtest86+は40回passしていた。少なくとも電源とかマザーボードとかいったあたりが 原因でおかしいというわけではないようだ。
_ Ubuntu 19.10 のメディアを作ってzdbをやってみると… -d はいろいろ言われつつも 完走するが、-cc すると途中で止まってしまう。 これは以前起きていた症状と似たようなもんだろう。 zpool importはできるものの、scrubするとやはり途中でpanicを起こしているようで、 これがブートメディアの場合は問答無用で再起動かかってしまうだろう。たぶん
_ ハードディスク側の問題か、それともおひっこし前のストリームがすでに壊れているのかを 切り分けなければいけないらしい。 WDのNAS用ドライブなのでWestern Digital Data LifeGuard Diagnostics を動かす。 あらためて入れずともすでに入っていた… のはなんでだっけ？ いずれにしろ これでハードディスク側の問題かどうかがある程度はっきりすると思う。
_ ものすごく深いことを書いているわけではない気がするが、逆に知らないままだと まずいだろ、というレベルを満遍なく扱っているように思う。
_ 2つ残念な点があって、ひとつは刊行時期によるものか、 C#8のことがほとんど書かれていないというもの。もうひとつは、それぞれのトピックについて さほどボリュームのある説明がなされているわけではないというもの。 C# によるプログラミング入門 | ++C++; // 未確認飛行 Cを手がかりにMicrosoftのドキュメントを見るだけで十分だったかもしれない。
_ 通称CLR MDらしい。デバッガ関係の資料見ていて何度か出てきたのと、 ↑のHigh performance本にも出てきた。WinDbgのスキル不足を補うために 使えるかもしれないと思い試している。しかし眠くなってきてしまい 新しいものを始めるコンディションではなくなってきたかもしれない…
_ ずっと昔に作ったFreeMindのmmファイル (XML) を解析するやつ、のようなものを 作る必要が発生し、しかし当時のソースを流用するのも芸がないし、 どうせZHTのプロセッシングで見直さなきゃいけないわけなのでF#で作り直してみるかーということにした。
_ F# の Type Provider をフル活用したFSharp.Data はたしかにすごいんだが、 別にそこまで大袈裟なものでなくても… という気がしてしまったのと、 型を構成するために都合のよいサンプルXMLを用意するのが億劫だったので 従来通りSystem.Xml.XmlDocument をベースにやることにした。 どうせZHTではノードを一部加工しながらほぼそのまま出力するというような 作りにせざるを得ないので、その予行演習にもなるだろう
_ XPathというやつをきちんと理解したのは ここ1年かそこらという状態なので そのあたりを少し勉強。 XPathというものの出現はXSLT 1.0とほぼ同時らしく20世紀の話だったらしい。 それから20年近くそういう要素技術があることを把握していないままというのは 我ながら驚くほかない…
_ で、XmlDocument.SelectNodes で帰ってきたものをsequenceにするには、 Seq.cast<XmlNode> とするらしい。
_ そういえば System.Xml.Linq にもXMLのアクセス用のクラスがある。XDocumentとか。 LinqといえばF#だと別にすすんで使うもんでもないような気がするがどうなんだろう。 Query Expressionsというのがあるし、 LINQ to Object 以外ではやはりこっちを使うのだろうか。しかしFSharp.Data とかもあるのでどっちがいいのかは場合によりそうな気もする。
_ LINQ to XML vs. DOM (C#) | Microsoft Docs。 うーん… 実のところXDocumentも多少は使ったことがあり、 XMLを作るときはともかく読むときは別にXmlDocumentと大差がない気がするなあと 思ったことを覚えている。そしてDOMから入った身としてはXDocumentは DOMっぽくない部分がDOMっぽくなくてなんか混乱するなあ (ひどい表現) と思った。 とはいえDOMでとれていたものがとれなくなっちゃうといったことはなかったはずだし、 今のご時世にXmlDocumentを頑張って使う必要はないのかもしれない。
_ Chromeのextentionで、ページの要素を選ぶとそれにあたるXPathをつくってくれるらしい。 ふむふむ。
_ 寒い。寒いが湯たんぽ効果で寒くて眠れんということはないし 歩いている間は寒いほうがいろいろ着たままでよいので楽だ。
_ Data LifeGuard Diagnostics は QuickもExtendedも完走した。 ということはディスクにも問題がないということになりますかなあ〜
_ も う1回だけ当時のストリームを戻して行く末を見てみるか。recv終わった直後に zdbでscrub的なことをしてみたりで、次も同じ結果になったらセットアップからやりなおしだろうか。
_ …… おお、zfs recv した直後のプールでzdb -cc したら完走しない。 このストリームはすでに死んでいたらしい。じゃあ作りなおしかなーもともと 引っ越し前のドライブはすでに壊れかけのものを一時的に使っていたので こういうこともあるんだろう。streamが壊れていたというのは予想外だったが、 まあ考えてみると表面的にはうまく動いているように見えて実はだめだった、という パターンなのかもしれない。そして10日くらいしかもたないのはscrubのスケジュールにも 関係していたのかもしれない。
_ Ubuntu 19.10 はたしかインストーラがZFS root に対応してくれていたはずなので 試してみた… が、インストーラが途中で落ちてしまった。2回。なのでいつもの Ubuntu 18.04 Root on ZFS を参考に やってみた。debootstrap を bionicのまま実行してしまって起動せず… が1回、 update-initramfs がどのカーネルも見つけてくれずに起動せず…が2回。 なんでだめなのかを理解できなかったのでやむなく18.04LTSを入れてから アップグレードすることにした。
_ CLR MDをいじる。 Tutorialsに書いてある内容をきちんと読んでおかないといろいろうまく進まない。 うまく進まないから読み直してみるときちんと書いてある… という感じ
_ で、これを使ってがりがりとプログラムを書いてゆくのも時には必要かもしれないが、 どちらかというとこれはF# Interactiveなどから使えるようにしたほうが便利かも？と 思えてきた。CLR MDの構造さえ理解できていればWinDbgとSOS.dllのコマンドのかわりに F# が使えるようなもんだ。もっとも Getting Startedに書かれている通り、32ビットプロセスにアタッチしたり、 32ビットプロセスのダンプを解析したりするときには こっちも32ビットプロセスになってないとだめなので、fsi.exe を2系統用意しておくのは なんか無駄な感じがしないでもない。
_ Interactive Service: Embedding F# Interactiveによると F# Interactiveを自分のプロセスに組込むこともできるようなので、 そっちの方が小回りが効くだろうか
_ ダイナミックマイク。スタンドは1000円くらいのもの。 ミキサーは家に転がっていたUA-3D。 18年ほど前に買って、 ろくに活用しないままだった。ギターと一緒に活用 しようと思っていた時期もあったが、PCにつなげるなら Rocksmithのケーブルの方が便利だし、そもそもギターをほとんど触っていない…
_ TEAMSは、周囲の音がある状態だと全指向性マイクでは会話が成立しないような感じなので これでどの程度効果があるか試してみたかった… のだが、これのセットアップをしている 最中に、実はOSのデフォルトの音声入力デバイス設定と、TEAMSの音声入力ソースの設定は 別だということに気付いてしまった。なのでマイクをつなげていてもTEAMSは ノートPCのマイクをそのまま使い続けていたことになる…
_ なおこのマイクはいかにもマイクという感じで安物っぽさもないしいい感じがする。 マイク部分は金属の網々になっているのだけど、 ピントが合わずにひっくり返りそうになる特性が 発揮されるのでずっと見ていることができない
_ スタンドに立てて目の前に置くことになるので、さすがにポップガードが必要かな？ しかし普通に買おうと思うと高い。ちゃんとしたもの買わないといかんという戒めを 述べている人も多いがそういう人達はボーカルの録音とかの話をしているので、 別に私の声が少々こもった感じがしようがポップノイズに比べればまったくましというべきだろう。 以前「テレビ会議中」ということをアピールするためにB6くらいのカードを 掲げることができるPOPホルダー的なものをまとめ買いしたのだけど、それが ちょうどよい感じにマイクの手前まで伸ばせそうなので、そこに何かガードができる的なものを 括りつけられればよい気がする。まあ↑に書いた、直視できない網々も ポップガード的な役割を果たすことになると思うので、あんまり神経質にならなくても いいのかもしれんが
_ パイプライン演算子やらを駆使していろいろがんばっていると デバッガで止めるというのがちょっと大変？途中を流れているオブジェクトの様子を 見たい、というときにはデバッガでトレース実行しながら…ということになるんだが、 だいたいその見たいオブジェクトというのはパイプライン演算子で渡り歩いてゆくそれなので、 「それ」を見ることができないと大変という話
_ CLR MDのつづきを時間をみつけてやる。 TutorialではLINQを使っている。こうやって見てみると、 大量のリストから抽出かけたり集計したり、という用途ではやはりLINQのクエリ式の方が 便利に見えてくる。 LINQに対する印象は10年ちょっと前と大きく 変わっていない。そしてきちんと身につけるタイミングを逃しつづけて いたという状況も大きく変わっていない…
_ で、まあお手本もあることだしF#でもやってみるか…とチャレンジしてみた。 F#ではquery というComputation expressionでクエリ式を 記述することになる。しかし文法やキーワードが微妙にC#のものと異なる… 違いとしてはさほど大きなものではないのでだいたい機械的に置き換えることができるものの、 クエリ式にベース言語ごとの違いを出す必要がどこにあるのか感がある。VB.NETのクエリ式も それはそれで違うらしいし… 敢えて変えたというよりは、実現方式からそのようにするほか なかったということだろうか…
_ それにしてもComputation expressionsはクエリ式なんてものが実現できるほど柔軟だったとは 知らなかった… と思いながらFsharp.Core/Query.fs を読んだらちょっと眩暈がした。 とはいえComputation expressionsであればBuilderの中も少しは読みようがあるかな… と思い、For から読もうとしたのだが… 今の私では読み進める前に心身が危険を感じて 睡眠を要求してくる感じがする。
_ ドキュメントを読む限りでは、select で新しい列を作って返したい、というときは tupleで受ける例ばかりだ。Anonymous Recordとか使えるのかしら？ と思ったが そうでもないらしい。まあすぐにパターンマッチに仕掛けて加工するというユースケースが ほとんどだろうから特に問題ないのかもしれない。
_ なおlinqで検索をかけるとめんこい女の子が何人か並んでいる様子がたくさん出てきて 面喰らうが、まあCStringよりはましかもしれない
_ 結果を見ていろいろ加工する、となるとUIはそれなりにリッチな方がやりやすい気がする。 JupyterとかLINQPadの中で使えるようにしたいところだが‥
_ lprunという スクリプティング的な環境があるようだ、どちらかというと LINQPadの豊富なoutput formattingだけを使わせてもらいたい、という感じなんだけど
_ Samplesの中にあるInteractive Regex Evaluator は正規表現を組み立てるのに 便利だと思う。似たようなものをJavascriptで作っているので使うことはないかもしれんが…
_ LINQPadはF#にもしっかり対応している。Jupyterで凝ったことをやろうとすると コンパイルエラーになったときに追うのがちょっと大変なこともあるので、 適宜DumpができるLINQPadの方が便利な場面が多いかもしれない。 Dump は渡したやつをそのまま返してくれるので、 パイプラインの途中でDumpを気軽に挟むことができる。なんだこれ便利すぎないか
_ いろいろ勉強になった。本題の計測に関する件以外にも、 こういう書き方をしたら遅くなる、というようなものたちについて、 実際のところどのくらい遅くなるのか？ というのをいちいち計測してくれていて大変に参考になる。
_ あと、各章の冒頭にあるエピグラフもよい。章の頭にあるのもエピグラフと呼んでいいのかどうか いまひとつ分からんが、そういうやつ。 アインシュタイン、ファインマン、マズロー、などの常連のほかに、 Blaming perf issues on Garbage Collection is like blaming your hangover on your liver... Its the thing that's saving you from your code (意訳: パフォーマンスが出ないのをGCのせいにするのは 二日酔いになったのを肝臓のせいにするようなもんだ) とか、 Segal's lawなど。
_ 牛すじの加熱時間と温度のことを調べている最中に見つけた。 いろいろ勉強になる。写真もいい。 そういえばO'Reilly Online Reading には Cooking for Geeksをはじめ 料理関係の本もいろいろ収録されているのでそちらも合わせて読もう。
_ Jupyter は #r で参照を追加できるので、Microsoft.Diagnostics.Runtime を追加することで 手持ちのコードが動くようになった。ただオブジェクトの中身を表示… ということだと やはりLINQPadほどすばらしい出来というわけではないように見える。
_ LINQPadもReferenceで参照設定が可能なのでそれで試してみよう…としたところ LINQPad6が出ていることを知る。入れた。
_ ...LINQPadでもreference追加したら普通に使えるようになった。 ああべんり
_ Visual Studio の中のF# InteractiveはIntellisenseがきかない。 まあ.fsxを作って適宜FSIに飛ばす、というのが想定される作りみたいなのでそんもんなのだろうか
_ F#を問い合わせ言語として使う場合のことを考えると、 LINQPadは出力のフォーマットはすばらしいが、インタラクティブではないので毎回実行しなおしになるので、 CLR MDでアタッチしながらやるのはむずかしそう。クラッシュダンプならそうでもないかもしれない。 Jupyterは、インタラクティブにやるのには適しているが、出力のフォーマットがいまひとつ。 F# Interactive も同じような感じだろうか。となると、fsxで書いといてF# Interactiveで 実行させるのが結局のところ一番なのかもしれない。Visual Studio Codeでも似たような 状態が作れると思う。
_ 12月に思い切って買ったもの。 そろそろ使い切りそう。効果はどうだったのかというと、もちろんすっきりするし 目の霞みも軽減されているような気がするけど、それはハイエンドの部分によって そうなっているのかという実感がない。 同じものを買っても効果の違いがよくわからんので、同じメーカーの価格が1/3くらいのやつ 「新サンテドゥα」を買ってみた。成分表を比較してみると、 ハイエンド目薬の方が配合している成分の種類が多いようだけど、 ハイエンド目薬が謳っていた有効成分最大配合的な4項目については同量搭載しているように見える。 ？？？
_ ざっと見た感じ、抗炎症成分が少ないように見える。あと結膜 (白目) の充血を抑えることを 主要な効能としている成分 (塩酸テトラヒドロゾリン) が配合されていないようだ。 たしかにこのハイエンド目薬は点眼してすぐに充血が解消されていたような気がする。 これがハイエンドではない目薬ではどんなことになるのか？ なお「サンテドウ」は、「ド」が小さくなっているという難易度の高い表記だった。
_ serializeしたオブジェクトを受信したらDumpする… というサーバを書いて LINQPadで動かしてみた。 外からそのサーバにobjectを送りつけてみたら普通に表示された。 おや、これはとても便利なのではないだろうか。 ネットワーク接続が大袈裟ならファイルの監視でもいいし…
_ ファイル監視に直してみた。これは便利… なのだけど、BinaryFormatterを使う場合は 対象のオブジェクトがSerializableでないといけない。 XmlSerializerは受け側で型が分かっていないといけない。
_ LINQBridgeVsは、 「How it works」を読む限りでは、LINQPadに飛ばすためにそこまでしなきゃいかんのかと 思えるような大がかりなことをしているようだ。 もっとゆるふわにやりたい…
_ 久しぶりにゴアテックス配合の靴。初日の、ポータブル拷問器具的な攻撃力はなくなり、 まあ痛いけど怪我するほどではないかな？ という程度で済んでいる。まだ長距離を歩くのは むりそうだが、じきに慣れるだろう
_ WinFormsでテストアプリを作って、へたに汎用性のあるものができあがってしまうと そこにいろいろ機能を盛り込みたくなってしまい、結果コントロールだらけの画面になってしまう。 タブでページを分けて… というような安易な 解決策をとった結果、見た目としてはそこそこまとまってくれてうれしいものの、 同じフォームの中であれこれやっているだけなのでフォームのコードがでかくなる。
_ タブに分けることができる程度にグループ化はできているので、これを別モジュールにして 集めてタブとして表示、なんてことができればだいぶましになるような気がしたので、 試しにUserControlに移行してみた。これ自体はほとんど問題なく進んだ。 タブにあるコントロールをUserControlに追いやって、関係するロジックも引っ越してきて、 フォーム側と連携しなきゃいけない部分はインターフェースなどを駆使してがんばって、 というのはある程度機械的にできるのでよい。問題はイベントハンドラだ。
_ TabPageからUserControlに引っ越すには、TabPageにあるコントールをcopyなりcutして、 UserControlにPasteする…ということになるんだが、イベントハンドラは引っ越してこない。 通常のコピペであればさほど不自然な動きではない… のだが、今回のように引っ越しを目的とした cut and pasteなりコピペであれば、イベントも引っ越してきてくれないとちょっと不便。 Clickくらいならまあ見ればわかるのでよいけど、もっと細かいイベントを設定しているときに それを引っ越し先で設定し忘れる、というのは悲しい。
_ イベントもいっしょに… という内容だと、 c# - How to copy events associated with control when copying controls? - Stack Overflowとか c# - How to copy events associated with control when copying controls? - Stack Overflowなどが見つかる。 が、同じFormの中でしかできないような？
_ しょうがないのでReflectionを駆使してローカルで登録しているイベントハンドラを とってみようか… と思ったらこれがなかなかむずかしい。関係しそうな記事として c# - Determine list of event handlers bound to event - Stack Overflowというのを発見したんだが、プロパティシートにある あらゆるイベントがこれで処理できる…ようには見えない。よく調べないで書いているが イベントの発生元がUnmanagedのほうなのか、そうでないのか、などでいろいろ違うような気がする。
_ などと書いている最中に、デザイナが生成したソース (*.Designer.cs) を解析して イベントハンドラの登録っぽいやつを抽出したほうが早いのではないかと気付いた。 立ち止まってよく考えることは重要だなあ〜 なお、 引っ越し元にハンドラを残したまま忘れてしまう、という ケースもあるが、引っ越している最中にハンドラのコンパイルが通らなくなったりして 気付くことが多いし、最終的にコントロールがいなくなれば未使用のprivate methodとして 検出できる…ので、それを消すことでほぼ対応可能だと思う。
_ あちこちの催しものが中止になっているがリテールテックは予定通り実施するらしい。 もう何年も行ってないし今年も行くことはないと思うが… なお今年はビッグサイトじゃなくてメッセらしい。メッセももう10年近く近付いていないような気がする
_ それにしてもこんな調子で各種催しものやら、その後に控えているオリンピックやらで 海外の観光客を迎え入れていいのだろうかという感は抜けないが
_ 人から人に感染するし、感染力も決して弱くない、と確定するまでにずいぶんかかったという 印象があり、その間にだいぶ広範囲に 広がってしまったような… 10万人規模の感染者が出たときにもうそれを 抑え込むことが可能なんだろうか… もはや武漢への渡航歴がない人達にも広がっているわけだし、 都内に通勤している人にも感染者がいる…ということになると、 いつ自分がかかってもおかしくないし、自覚症状が出るまでにさらに撒き散らす可能性も あるわけなので、まったくどうしたものやらという感じがする。
_ ZoLがどんどん進んでゆくのに比べるとZoFのintegrationの動きがあまり見えず、 この調子ではFreeNASにまで降りてくるのは相当かかるだろうなーということが 気になってきた。すぐに乗り換えるかどうかはともかくFreeNAS以外を検討しておいても いいんじゃないかという気がしてきた。まだストレージサーバをLinuxベースにするほど Linuxに対して心を開いていないというのは変わっていないが… 普段Linuxを使っていられるのも バックボーンとしてFreeBSDとかそういうサーバがいるから、というような気持は あいかわらず残っている。損しかしない偏見のような気もするが偏見だけに覆すのはむずかしい
_ XigmaNAS は、FeaturesのところにOpenZFSと書いてあるのでひょっとしてもう移行済？ 試してみたところ、XigmaNAS 12.1.0.4 は FreeBSD 12.1-RELEASEベースで、 まだZoFは入っていないものだった。zpool-featuresは、large_dnodeとspacemap_v2が 追加になっている程度だった。なおXigmaNASは以前はNAS4Freeと呼ばれていたもので、 軽く眺めた限りではドキュメントが必要最小限という感じで、また FreeNASほどBoot Environmentの制約が厳しくないように見える。Webからjailを作ったりも できないように見える。 ただリリースサイクルはFreeNASよりも随分速いようなので、待たされる度合いは 少ないのかもしれない。
_ とりあえずZoFを触ってみないと話にならん…ので、FreeBSD12-STABLEを試す。 portsから入れるしかないのかな？ pkg install ... では見つけてくれなかった。 もともとカーネルに入っているやつとどう切り替えてゆくのか、 とか、ブート環境をZFSにできるのか、などといったあたりのガイド的なドキュメントが 見当たらないのでけっこう辛いかもしれない。ひとまずportsで入れようとしている‥ が、まず依存するやつらを入れているので時間かかりそう
_ …… openzfs-kmod-2020011300 is marked as broken: fails to build だそうだ。 -DTRYBROKEN でビルドしてみる… 普通にコンパイルできた。ひとまず続ける
_ 結局、もともと入っているZFSを避ける方法がいまひとつ分からんし、今回は ちょっとした実験でしかないので、UFSでインストールして、OpenZFSを入れて、 /sbin にある zfsとzpoolをどけて、kldload openzfs した後にpoolを作ってみた。 でzpool get all [プール名] としてみたところ… Ubuntu 19.10 で作ったものと比べて 「edonr」というfeature以外はぜんぶ揃っているようだ。edonrが使えない理由がいまひとつ 分からん。STABLEだとこんな感じだったが、CURRENTだとまた違うのかな？あんまり 違わない気がしないでもないが…
_ CURRENTのsnapshotを見る限りでは、portsのsysutils/openzfs-kmod は同じだった。 となるとあまり試す意味はなさそうだ。あとはGitHubにあるソースを1からビルドしてどうかという 感じだろうかー、そういえばソースをきちんと読んだことがなかったので落として眺めてみよう…
_ なんかedonr使えるっぽかったのでREADME.mdの手順に沿って入れてみた。
freebsd-zoftest# zpool upgrade rpool This system supports ZFS pool feature flags. Enabled the following features on 'rpool': edonrヤッタネ
_ でUbuntu 19.10で作ったstreamをrecvすることもできたようだ。よかったよかった
_ で、どうするかというと…どうなんだろう。FreeNASの機能に強く依存する生活は 送っていないものの、かといってFreeBSD-STABLEで、かつZoFのHEADで生きてゆくほどの 覚悟は持ちかねる…ので、結局のところ普段使っているOSと合わせたほうが幸せという やる前から分かっていた結論になるのだろうか。それはいやなんだよね (堂々巡り) まあUbuntuでサーバ作ればDockerとかも動かせるのでこれまで苦労していたものが いろいろ楽になるという面はあるが、一方でストレージサーバになんでもかんでも 詰めこんでしまうというのはそれはそれで違う気もする。
_ なんだかデフォルトの吐き気があるな…なんだろ
_ Saturn/Azure/Fable/Elmish でSAFEらしい。F#におけるLAMPみたいなもんか
_ 個人的にはASP.NETやASP.NET Coreには必要最小限の関わりかたしかしていないので Giraffe + Saturn よりも Suave の方がしっくり来るところだが… FableとElmishでクライアントサイドもF#で書く、というお話らしい。
_ あまり体調が優れないので昨日は酒飲まずにさっさと寝た。 途中何度も目が覚めて、あれーけっこう酔っぱらっている？ いやいや今日は飲んでないし… というような不思議な脳内のやりとりをした。まあなんだかんだで身体は少し休まったのかもしれない
_ 一方ここ数日は指の痛みがかなり強めだ。右手の薬指〜中指がけっこう痛くなってきており、 なんだかんだでほとんどの指にテーピングを必要としている始末だ。
_ NetBSDにはZFSがかなり早い段階で入ったものの途中で放置状態になったように見えていたが、 最近になってまた入りなおしたらしく、9.0はそれが含まれた状態でリリースされているらしい。 ということで久しぶりに触ってみる
_ 私は前職の頃はデスクトップOSとして、現職になってからはサーバOSとして、 たぶん8年くらいずっとNetBSDをメインで使っていた。 とはいえもう10年くらいブランクがあるので本当に久しぶりだ。 緑色で出てくるカーネルメッセージを見た瞬間に懐しさがこみあげてきた。
_ さてpkg… 入れるコマンドをすでに忘れている。pkg_add のままなのか。 あとシステムの設定をいじるテキストベースUIのコマンド名も忘れていた。 sysinst だったらしい。たしかもうちょっと和風な名前のツールもあったような… sushi だっけ？ 見当たらないので気のせいかもしれない。
_ それはそれとして、配布サイトにビルド済のパッケージがまだ配置されていないように見える。 9.0のディレクトリがない… しょうがないのでpkgsrcから入れる。時間がかかる。 そしてZFSは特に追加で何かを入れなきゃいけないということはなく、 modload zfs すればすぐに使えるみたい。
_ pool作ってみた。feature flagsは12こしかない。 FreeBSD 11.2-RELEASEの段階で17こあるので、 もっと古いバージョンがベースになっているのか、はたまたZFSの外側で必要としている 要素が不足しているのか… いずれにしてもFreeBSD側のZFSの実装も大きく変わるわけだし、 ZoLも含めてOpenZFSできちんと統合されるようになればわりとよりよい未来が 出てくるのかもしれない。自分自身で何か力を出すわけではないのでそのへんについては 期待以外のものはないのだが…
_ インパクトのあるタイトルだ。
_ ここのところ頭痛が続いている。
_ 里親さんがお子様を伴って帰省されるということで、その間うちで預かることになった。 なんだかんだで年2回くらいのペースで再会できている。 ジョンはこちらのことを完璧に覚えていて威嚇されることもなく数時間後には いつもの日常チックに馴染んでしまうのだけど、それでもやはり久しぶりに会うときには こっちのことを忘れているんじゃないかという不安があったりする。
_ 幸せ太りなのか、かなり増量しており、片手で抱えていると数分後には限界を迎える程度には重い。
_ 水曜にうちに来て、来週月曜までいてくれるらしい。今日は妻とキャンプに出掛けているらしい。
_ はやとの後輩。 高齢？ のマルチーズ。立ち居振る舞いがコパンを思い出させるものがある。
_ 悪性腫瘍を除去した直後で、腎臓や膵臓の数値もよくなったり悪くなったりで目が離せないようだ。 何よりあまり物を食べようとしないのが悩ましい。腎臓・膵臓に悪影響があるものは 避ける、というともう脂肪分や塩分、蛋白質などを減らさなきゃいけないので ただでさえ食べられる選択肢が少ない上に、食べたがらない、 となるともはや生命維持が危ぶまれるレベルだ。数値が改善しているときなどは わりと元気に歩きまわっているのだが、どういう状態でバランスをとるのが正しいのか… 我々は間接的に見ていることしかできないので心配するほかない。
_ アップデートが降ってきたので上げたところ、Update Train EOL Reached と言われた。 STABLEのTrainにいるので次が出てないのにEOLと言われても困るんだけど… と思ったら11.3-RELEASEが出ていたらしい。先月末か… 気付かなかった。
_ めがねに吹きつけて拭くだけでピカピカになる…といったようなものではなかった。 水で洗い流す必要があったとは。というか主成分は界面活性剤なのだから まさに「シャンプー」なのだな… 綺麗にはなる。
_ 三連休は、昨日の夕方に少し出たくらいでほとんど休んでいた。 今日は、いつもなら感じるはずの目や頭のだるさがあまりなく、 集中できている感じがする。ひょっとして休んだからだろうか？
_ ジョンは昨日の午後に帰っていった。短かい間だがとても楽しかった。 あちこちマーキングをして、しかもトイレシーツのないところにしたがるとか、 外に人が通るたびに吠えるといったあたりはあいかわらずで困ったもんだが、 期間があまり長くないこともあり、根本的な対策、具体的にはしつけとかシーツの面積を 増やすとか、は、とくにやらないままだった。
_ ほぼ毎日外で遊ぶことができた。週末は、亀戸天神、水元公園、浅草などに長い散歩に 出た。水元公園は里親さんと初めてお見合いした場所だし、亀戸天神は犬がいるときは 毎年訪れている。浅草も長い散歩のときにはよく通っていた。いずれもジョンにとっては、 というか、ジョンを伴った私たちにとっては思い出深い場所ばかりだ。
_ 来たときは抱えているのが苦痛なほど重かったジョンが、食べるものはほどほどで、 運動をたっぷりさせたところ、みるみる引き締まってきたのには驚いた。 樽のような腹にきちんとくびれができている。わずか4〜5日でここまで変化があるとは…
_ 加齢によるものなのか、太ったことによるものなのか、以前のような無尽蔵の体力では なくなってきたようだ。横になって寝息を立てることが多かった。ジョンと 一緒に住んでいた頃にジョンの寝息やいびきを耳にしたのは本当に数えるほどしかなかったのだが…
_ ジョンにとっては知った顔ぶれだと思うので、さほどストレスがある生活ではなかったとは 思う。たまに、キャリーの中に入ってじっとしている時間帯があったくらいで、それ以外は ベッドに一人で横になっていることも多かった。こうやって半年に1回くらいのペースで ジョンの記憶が薄れないままの関係を保つことができれば、我々夫婦にとってはとてもよいのだが、 と思う。
_ ジョンが来た日？くらいに左膝を痛めたようで、しゃがんだり、そこから立ち上がろうとすると 痛みが走るようになった。で昨日、シャンプーが終わったジョンをしゃがんだまま抱えていたときに 足首の、足の甲側に痛みを覚えるようになってしまい、こっちは歩いているとけっこう痛い。 寝て起きてもまだ痛いままだったので湿布をした。こんなことなら昨日のうちに貼っておくんだった
_ 国内ではこれから大流行に向かうか、収束に向かうかの境界線あたりにいるようだ。 決して肺炎を甘く見ているわけではないものの、致死率は決して高くないので 「殺人ウィルス」みたいな言い方はどうかと思うし、現実問題として 潜伏期間の長さや症状が悪化しないまま回復してしまう人が一定量いる以上、 自分がそれにかかる確率が低いとは言えないと思っている。せめて「感染したこと」が 個人レベルで特定可能な時期に感染しないで済むことを望むほかない
_ 在宅勤務みたいな話も周囲で出ている一方で、学校とかはそういうわけには なかなかいかないだろうし、受験シーズンだし、いろいろ大変そう。
_ ずっと先送りにしていたマイナンバーの住所変更をした。住民登録とは連動してないので 別々にやらんといかんらしい。そしてついでにマイナンバーカードの申し込みをしてきた。 これがあると確定申告の手間がだいぶ減るらしい。しかしマイナンバーカードは申請してから 届くまで1〜2ヶ月は平気でかかるらしいので今年は手遅れらしい。
_ ガチャ目、なんていう用語があって、あれはもうちょっと穏当な表現がないものか？と 探してみたところ結局のところ表題の用語になるらしい。
_ マイナンバーカードに貼付するために写真をとったのだが、正面を向いているはずなのに 左の目が少し下がっているような気がする。私はガチャ目だったのか (穏当な表現はどうした) あまり写真をとられるという経験がないから気付かなかっただけなのだろうか。
_ なおガチャ目は不同視、つまり「左右の視力が大きく異なる状態」のことを指すこともあるようだ。 というよりそういう用途で使っている人の方が多いような
_ 人類が滅亡するようなことが起こったとき、それはどういう原因によって 引き起こされたものなのか？みたいな滅亡シナリオ的な話を読む限りでは、 核戦争、気候変動、などに並んで疫病というのが挙げられており、それ以外では 地球外生物とか人工生命体だとか、人間以外の生物がやってきてまずい、 みたいな話もあったりする。
_ 疫病に関しては、 何年か前に見たGatesのプレゼンを思い出す。 新型コロナウィルスの話は、大流行してほしくないというのはもちろんだけど、 そこまで神経質にならんでもいいような気が一方ではする。かかったら即死みたいな イメージで過敏に反応する害の方が大きいんじゃないの、というような心境。 で、このレベルのものであっても流通だけでなく経済に大きな混乱をもたらしている様子を見ると、 滅亡とまではいかなくてもしんどいことはたくさん出てきそうな気がする。
_ 単に必要なものが手に入りづらい、手に入らない、というのであれば自然災害のときにも 見られた現象だが、それに比べると期間も範囲も見えない (そしてより規模が大きいという 蓋然性の高い予測だけがある) という点で問題は深刻かもしれない。マスクしろと言われて そのマスクが手に入らないとか… 買占めに走る行動は自身が必要としている以上のものを 備蓄として買い求めるという以外に、転売を目的としたものもあるようで、 繰り返しになるがこの段階でいろいろ本性をあらわす人がこれだけ目立つところを見ると、 世界というのは波風が少なく動いているようで、実は非常に微妙なバランスで成立しているのかねーという感じがする。 その「感じ」はもちろん偏見も含まれているだろうけども、そんなに大きく外れてないんじゃないの？という拭い難い感覚があり、 そういう感覚は決して快いものではない。少なくともこの状況を悪化しないための努力は ありえても、よくするために自分にできることはほとんどないという無力感がある。
_ まあ私の感受性はいろいろバグっており、 ウィルスは熱に弱いので予防のためにお湯を飲みましょう、みたいなTweetを読むだけで 何日もうんざりした気分をひきずってしまうので困ったものではあるのだが…
_ 先日とりあげた 【3868】コンサータによって自己の連続性を失いつつあるにはもうひとつ発見があった。 質問者がコンサータによって「感覚過敏」が解消され、ゆっくり本を読むことができるようになった、という記述があり、 そういえばDr林が過去に発達障害に関連したQAで同じ用語を使っていたことに思い出した。 靴下や靴が履けない、といったような事例が多かったように思う。 で、自分が悩んでいる感覚も結局これと同じようなものなんじゃないか、と、 ようやく思い至った。この、自分の悩みに名前がつく (ついたような気がする) という経験は 非常に重要で、それによっていろいろ調べる手がかりになったりする。
_ 感覚過敏は、いろんな感覚が人より過敏になっていて、普通の人なら問題ないことが 耐えがたい苦痛になったりする、というものらしい。視覚や聴覚にも存在するようだ。 私の場合は触覚、とくに鼻の先にそういう感覚がある。 とっくに埋もれている私のProfileにも書いてあるが、 たとえば私は子供の頃から仰向けで寝ることができなかった。仰向けになると鼻の先あたりが もやもやと、なんとも言えない違和感を覚えて耐えられない。 おでことか、鼻の近くに腕を載せるなどをすれば大丈夫。ただ寝ている最中はだいたい 仰向けで寝ており、そのときにその「違和感」のせいで目が覚めたりすることはないし、 夜中に目が覚めて再度寝る…なんてときには別に仰向けになっても違和感が襲ってくることはない。
_ あと、マスクを正しくつけることができない。 鼻の頭にそういったものが触れ続けることには耐えられないので、子供の頃は 鼻をカバーしないようなつけかたしかできなかった。今でも普通のマスクを鼻を覆うように つけることはできない。 唯一、「快適ガードプロ」という、眼鏡が曇らないように眉間〜鼻骨あたりにクッションがついた マスクだけはつけることができる。眼鏡が曇らないかというと、曇るような気はするけど、 この形状によって鼻の頭に触れることなく鼻を覆うことができるので、私にとっては 革命的なものだ (それでも体調が悪いときや疲れているときは耐えられないこともあるけど、 まったくつけられない他のマスクに比べれば救世主に等しい存在だ)。
_ 違和感は鼻の頭にほぼ集中しているので、眉間〜鼻骨あたりに刺激があってもあまり問題ない。 とはいえ、眼鏡を初めてつけたときはそれなりに苦痛で、慣れるまでに何日もかかったことを 記憶している。慣れることができるのであれば、鼻の頭だって慣れそうなもんだが、 今までこの苦痛を克服できたことはない。仰向けで寝ようと努力したことも何度もあるんだが。
_ そんな調子なので、仰向けにならなければいけないシチュエーションがとても苦痛だ。 歯医者、理髪店、など。理髪店に関しては1000円カットが救世主的存在だ。 仰向けにならなくていいし、さっさと終わらせてくれるし。 病気で入院なんてことになったら耐えられるかとても心配。
_ 触覚過敏で調べてみると、先程の靴下の件などが出てきたりもする。 いろんな事例を見た限りでは、 たとえばシャツの襟についているタグが不快だとか、 襟足と鎖骨の接触が不快だとか、そういう感覚は私にもある。靴下についても、 たまに爪先の縫い目部分が気になってしょうがない、という感覚があったりする。 いずれも我慢ならないというほどではないし、常に感じているわけでもないので、 鼻先に感じる圧倒的な不快感に比べればましなほうだ。
_ なお触れられて不快なのは自分の身体であっても同じで、指を鼻の頭の近くに持ってゆくとか、 実際に触るとか、もっと言うならそういう様子を想像するだけでかなり不快。プロレスの マスクマンは、マスクの形状によっては見ていると落ち着かない。 そういや関係ないけど、自分でくすぐってもくすぐったくない理由って何なんだろう
_ 以前Goで作った tail -F しつつ色つけたり加工 (グルーピングとか) しつつ表示するというツールは 今でもそれなりに便利に使っているものの、もうちょっとUIでいろいろ操作したり できるようにしたかったので試しにWeb化することにした。 Webサーバ側のプロセスでファイルを監視して、来たログを加工してWebSocketで ブラウザに投げる… というような作りを考えている。
_ 見た目はともかくWebSocketで通知するところまで作ってみた。 SuaveにWebSocketのサンプルがあるし、tail -f 相当の処理は F# Snippetsにあった (unix-like tail function) ので、そのあたりを組み合わせて、 あとはタスク間の同期をどうにかすることでひとまず動くようになった。
_ タスク間の同期はMailboxProcessorというクラスでやる。 WikiBooksにも記事がある。 これ自体の使いかたはとくに難しいことはなく、メッセージを組み立てるのも union type でがんばればよいので、Erlangのメッセージループのような感覚で 使うことができる。ただ複数の非同期処理をうまいこと連携させながら、 それでいてブロックせずにやる、となるとけっこう混乱する。MailboxProcessorは 中で受信ループをまわすことになるので、外との連携でまたBlockingCollectionなんかを 使ってみたりして、ちょっと制御構造がややこしい。必要であれば仕方ないが、 Erlangのプロセスやgen_serverの手軽さに慣れた身としてはけっこうしんどい。
_ WebSocketの方は、FINとopcodeのCloseの意味をきちんと理解してない状態で 組んでいたらいろいろおかしかったが、RFCやあちこちの記事を読み直して理解できたので、 だいたい理解/期待した通りの動きができるようになった。
_ スミソニアンが所蔵している物品の2D/3D画像を公開するサイトらしい。 FAQによると CC0 (Creative Commons 0) で公開されるらしい。すごいことだな…こんなことができるのか
_ こんなご時世だからこそお勉強会をしてゆきたい、という気持があるのだけど、 さすがに場所借りて集まるというのは濃厚かつ濃密な接触になってあまりよろしくない。 そもそも私自身が土日にあまり外出ができるほどの時間をとれない生活をつづけているので 少なくとも私が主催する「お勉強会」は1年近いブランクがある。
_ などということを考えつつ浮かんできたのは「オンラインお勉強会」という用語だった。 浮かんだのは用語だけで、具体的にどういう形態をとるのかについてはぼんやりとした イメージしかない。なのでそのぼんやりと連想した内容を以下に書く。
_ ここのところ会社ではTEAMSを導入していて、ビデオ会議の便利さを日々感じている。 思いつく限りの感想は以下のような感じ。
_ オンラインお勉強会としてのおおまかな形として、文字だけ、文字＋音声、映像、の、いずれかの 方式で参加可能な形態を考えている。 映像・音声のチャットに関しては、積極的に参加してもよいし、流すだけ、 といった形態でもよいと思う。 会話をしながら参加したいという人もいれば、それを眺めたいという人もいると思うので、 どちらも収容可能な環境を用意できたらよいのだが。 お勉強動画を見ながら作業をするのと 同じ発想で、他の人達が作業している様子を見ながら自分の作業をしたい、という人も いるだろうと思う、という発想。
_ PC画面の共有については、会話の途中で 参加者に画面を見て欲しいときに使えたら便利かな、という程度で捉えている。 もし常時PC画面を見せたいといった欲求がある場合は、各自で配信の環境を用意してもらって、 そのリンクを案内してもらえば済むかな…と思っている。
_ あとはオープンでありかつ一定の記録が残る可能性があるものなので、そのあたりのルールと フォローをどうしたもんか、というのは今のところあまり見えていない。 ブロードキャストを前提とした運営をするつもりはないけど、 参加メンバーが自分の判断の範囲で何かを公開する場合に、参加者の望まない情報が意図せず 漏れてしまうという可能性は考慮が必要そうだ。
_ ベースにするプラットフォームをどうするか？ 軽く調べた限りでは、
_ 先人がいるかな… と調べてみたところいくつか見つかった。 Zoom使ってるところや、 Appear.in というやつを使っているところなど。探しかたが悪いのか、 コア参加者とカジュアル参加者がいる、みたいな運用形態をしているところは 見つからなかった。
_ とくに今以上に私自身が頑張ることでよい方向に進むとは思えないときに では何をして何をしないのか、みたいな境地に至ると今までの原因→結果といった シンプルなものとはだいぶ物事の様子が変わってしまうのでむずかしい。 物事をシンプルに捉えすぎているからおかしくなっているのかもしれない。
_ PDFは私でも理解できる程度にシンプルだった。どうしたもんか