
カブトムシの餌を、高タンパクなKBファームのプロゼリーに変えてから、元気のなかったカブトムシも元気になってきた。
今週の半ばは、オスのカブトムシも元気だった。昨日、オスのカブトムシの元気がなくて心配だったのだが、今日の朝は動かくなっていた。足も閉じてしまったので、死んでしまったようだ。写真は、木曜日のもの。9月まで生きると思っていたのに。メスの3匹は元気なのが救いだ。

カブトムシの餌を、高タンパクなKBファームのプロゼリーに変えてから、元気のなかったカブトムシも元気になってきた。
今週の半ばは、オスのカブトムシも元気だった。昨日、オスのカブトムシの元気がなくて心配だったのだが、今日の朝は動かくなっていた。足も閉じてしまったので、死んでしまったようだ。写真は、木曜日のもの。9月まで生きると思っていたのに。メスの3匹は元気なのが救いだ。
まだ、イーサリアムのネットワーク不具合続いている。イーサリアム上に情報を記録しているサービスも多いし、イーサリアムのネットワークを使ったトークンコインも多い。イーサリアムのネットワークへの依存が大きいので、いろいろなコインやサービスに余波がある。これはこれで問題。独自にブロックチェーンのネットワークを作ればいいのだけど、1社でやろうとすると、維持管理も大変だし、分散型ネットワーク台帳の意味がない。イーサリアムには、GAS代の高騰問題もあるので、いろいろと大変である。
正常化は、Coincheckいわく、8月30日になるとか。28日からなので、長い。それまでパレットトークン(PLT)は下がり続けるのだろうか。下がってくれるとチャンスなんだけど。
WebEx Eventを使ったセミナーに参加したので、参加者側の所感をメモとして残す。
いくつかあるウェブ上のイベントツール(ウェビナーツール)と同じような形。ツールインストール型の方が安定するのはわかるが、参加者側に負担が増えるツールは、ちょっと。いくつツールを入れればいいんだろうか、という感じだ。

なかなかアートな感じでハラビロカマキリの写真がとれた。満足。
真間川に雷魚がいた。写真は取れなかったが、目視で確認した。
場所は、真間川と派系大柏川の合流ポイントだ。ミシシッピーアカミミガメが川の境界で甲羅干しをしているの見ていた。亀が真間川方向に泳いでいる後ろから魚も泳いできており、鯉かと思えば、雷魚だった。干潮のタイミングもあり、水深がなく、はっきりと見えた。江戸川かどこかからか侵入してきたのだろうか。
真間川はよく見ているが、雷魚は初めてだ。
昨日から、東京パラリンピックが始まった。またテレビは、スポーツ番組ばかりになるかと思っていたら、パラリンピックは民放局でのテレビ中継がない。NHKでの放送でしか、パラリンピックの競技がみれない。
この前まで、放送局はSDGsだの、ダイバーシティだのと言っていたのに、パラリンピックの中継はやらないという。パラリンピックが取り上げられているのは、学生の観戦の有無とか、そういうことばかりだ。そんなことよりも、パラリンピックの競技の紹介や中継などを行って、多様性への理解を促す方が良いのだが。こうなると、SDGsとか言っても、言葉遊び程度にしか考えていない番組編成なんじゃないだろうかとも思えてくる。
折角の自国開催のパラリンピックなのに、つまらない。障害への理解には、ほど遠い日本だなと悲しく思う。自分ができているかというと、そうでもない。だからこそ、知ろうとしなければならないのに。
ChromebookのLenovo Ideapad Duetで、Google Meetをすると、背景のぼかしやバーチャル背景を使えない。たぶん、CPUの性能のためなんだろうけれど、不便。設定にも出てこない。映りなどに問題はないので、ここは残念だ。
それから、Chromeでも、Google Meetアプリでも同じくできない。PWAアプリだから、差があっても困るけれど。

カブトムシの飼育ケースの土が汚れたので、掃除した。捜索の結果、卵はいくつかあるのだが、孵化して生き残っている幼虫が見当たらない。前に調べた時には、卵が産み落とされていたわけで、孵化して幼虫が育ち始めるころだったのだが。くぬぎマットの状態が悪いのと、成虫にかき回されたのがいけなかったのだろうか。
1週間で3匹が死んでしまい、残り4匹。雄が1匹、雌が3匹。天気も悪くて、気温が安定しなかったというのも、死んでしまった原因のような気がする。成虫になってから、40日くらいにはなるので、そろそろ体力的にきついのかもしれない。エサもさらに高タンパク質のエサに変えて、様子見。来年にむけて、幼虫を増やさないといけない。長生きしてもらわないと。
分散仮想スイッチは、vCenter Serverに設定されるリソース。そのため、vCenter Serverをリプレイスするときに、前の設定を引きつながない場合には、再設定が必要になる。
分散仮想スイッチは、ESXiのホストやクラスタの設定ではないので、注意が必要。忘れるのでメモ。
SQL Serverへの接続に使用するポートは、通常、TCPの1433番ポート。デフォルトでインストールしたSQL Server(既定のインスタンス)しかなければ、これで接続できる。名前付きで、SQL Serverをインストールした場合は、SQL Server Browerサービスを使用することにより、1434番ポートで、UDPを使用する。
SQL Serverでポート番号を調べると、1433と1434が出てくるのだが、これをTCPだけで設定してしまうと、SQL Server Browerサービスを介した名前解決でエラーになる。エラー時には、エラー番号の26なので、SQL Server Browerサービスの起動を確認するのだが、これが起動されている場合には、UDPの1434番ポートが通信可能になっているかを通信経路上(SQL Serverのサーバと、経路のネットワークと、クライアント)で確認する。
Provider: SQL Network Interface, error: 26
さらに注意事項として、名前付きインスタンスが動的ポートで構成されるようになっている場合(デフォルトだと動的ポート)、1433番ポートを使用して、SQL Serverが起動していない。名前付きインスタンスの1つしかインストールされていない場合には、起動ポートを1433に固定することで、他のポートは空けなくてもよい。
参考: https://docs.microsoft.com/ja-jp/troubleshoot/sql/connect/resolving-connectivity-errors