スギちゃんを全滅させろ

スギさんとの戦いふたたび

ことしもスギちゃんとの戦いをはじめました。詳細は後に書きますが、つくしが顔を出す寸前のところまで来ていました。まず、昨年レベル分けして除去作業のレベルを変えてみた結果を書いておきます。1つめの写真は、地下茎を深く追わず、30~40cmほど土をひっくり返して見え付けた地下茎を除去した部分です。庁とのこの部分の上にトマトがびっしり茂っていたのでほとんど地面のメンテナンスができなかったこともありますが、スギナがびっしり生えてしまいました。しっかり除去したわけではありませんが、何も除去していないのと同等くらいの状況のように見えます。

つぎの2つ目の写真は、5,60cmくらいまで地下茎を追っかけて除去した部分です。1年間の間に数回除去したていどですが、スギナは数本しか生えていません。しっかり除去することは効果があるといえるでしょう。しかし、地下部分ではそうでもありません。この部分においても地下茎は広がっており、地下60cmほどの場所に水平に伸びていました。この地下茎からほぼ垂直にのびて次の芽を出そうしているものが多数ありました。3つ目の写真が、その垂直に伸びた地下茎です。

掘り出した根を伸ばして石の上に並べています。長いもので60cmほどあります。左側が地上方向で、それぞれ土筆が芽を出そうと地表ぎりぎりのところまで来ていました。これらは、60cmほど掘った後、横方向に順次掘り進みながら採取しました。

2020/ 2/ 9 15:59

これらは上の2番目の写真の箇所から掘り出したものです。いずれも地表面からは見つけることができませんでした。
 地上に少しでもスギナは生えているなら地下には地下茎が広がっていると考えるのが妥当でしょう。毎回60cmも掘って除去するのは大変なので定期的に耕して出てきたものをこまめに除去するのは作業量が最も少なくて済むように思います。もちろん除草剤を使えば楽に除去できるのですが、無農薬栽培を目指したいので、農薬は使用しません。何かを使うとしても自然界にあるもので対策したいと考えています。

活動量計 T-PRO Lifesense band2 想定外の電池切れ、半年ほどで寿命??

以前に電池の持ちについてレポートした T-PRO Lifesense band2 ですが、本日想定外の電池切れが発生しました。これまでは心拍計オンでも5日ほど電池が持っていましたが今回はフル充電した翌日に切れました。

 充電しても充電されるようすがありません。最近何かし違うことをしたかと言えば、USBの口つきのコンセントをかえたことです。まさかと思いながらコンセントを交換して充電しなおしました。復活?、100%まで無事に充電できたように見えます。昨日は間違いなく100%まで充電できていたので、1日でほぼ0%になったのは謎です。とりあえず心拍計オフでどうなるか様子を見ます。問題なければ、不具合のあるUSB充電アダプタで充電すると十分に充電できていないのに100%と表示されるということになるのですが…。 なんか納得いかない挙動です。

 別の観点で、今日何か特別なことをしたかといえば、特になにもしていない。接点をショートさせるような水気への接触などは特にない。 

 再現するのか様子見です。

スパム対策設定の成果

先のスパム設定の成果

設定対策後1ヶ月が経過しました。 先に公開した設定で、検出できなかったスパムは0件でした。 ただ、誤検知、つまり通常の配信メールなのにスパムと判定されたメールが4件ありました。これらは、除外設定で暫定回避して誤検出を抑制しています。

正式な誤検出対策の方法

誤検出を検出されたときに1件づつ除外設定をしなければならないのは面倒です。そこで、誤検出してしまった原因を確認して、その条件を除外することとします。
 DNSの逆引きで、unknownとなった送受信ログがあるものを対象としていますが、メースシステムの送受信でDNSで名前解決をせずに動作しているメールサーバーの存在が原因でした。つまり、メールの送信元がファイアウォール内のイントラネットであって、そこから中継サーバを経てインターネットに送信されています。

普通、メールサーバならイントラネット内でもDNSで名前解決するようにシステム設計するものなのですが、それなりにインターネットサービスをしている企業であっても名前解決・逆引きできないメールサーバがいくつかあります。DNS設定くらいしておいてほしいのですが、そんなことを言っても解決できないので、対処方法を考えてみます。
  問題はイントラネット内でのUnknownですので、Unknwonが10.x.xとか192.168.xとかのイントラネットIPなら除外する回避設定を正式対処としてみます。正規表現でUnknownかつ(10.xx.xx)でも(192.168.x)でもxxxでもない場合にスパムと判定するように見直します。といっても、メーラのフィルタにこのルールを設定できるのか疑問ですが。

スパム対策設定その後

先のスパム設定の結果と追加対策

対策前の1週間: 対象のスパムなどのメール は 284通。 これは振り分け前なので一部MLも含んでいる。 半数はスパム候補として判定されマークされている。一番対策したかったのは、メーラーやSpamAssassinでスパム判定し漏れてメインのメールボックスに入ってくる新しめ?のスパムでした。 100通/週くらいありました。

対策後の1週間;メインのメールボックスに入るスパムはほぼなくなり、1週間で2,3通でした。スパム判定の下メール内訳は次の通り、
先に追加したスパム判定ルールで検出したスパム:222通。うち、97通はメーラーやSpamAssassinでスパム判定し漏れたものでした。 追加したルールで引っかからず、メーラーやSpamAssassinで検出したものは157通ありました。 
 誤判定がないとは言えませんが、誤判定してしまうような環境から送信されたメールは不要としてしまってもよいかもしれません。数はほとんどないのでどうしても必要ならホワイトリストに入れることで回避できます。 スパムに困っている人は参考にしてください。

スパムメール対策 、おや多いと思ったら設定し漏れ…

最近スパムメールが増えてきたので、設定の見直しをしてみた。いくつかのパターンに分けて対策を試みる。

fromが自分のメールアドレスに偽装されているもの

このパターンは、一目でスパムとわかるので、まとめて削除できるが、事前に何とかならないか設定方法を見直してみる。
 このパターンは、サーバーで拒否してほしい。これは、送信元IPや送信元サーバーのドメインで判断できる。しかし、ここのレンタルサーバサービスでは提供されていない。仕方ないので、メーラで受信後に自動削除してみよう。
 メーラによって設定方法や設定ができるかどうか変わりますが、以下はThunderbirdでの設定方法です。
 ツール→メッセージフィルタ→新規→フィルタ名を入力→条件で”カスタムヘッダ”「Received」 に”次を含む”「.XXXX (unknown」を指定し、 動作に「メッセージ削除」を指定する。
  この設定で、 *.XXXX ドメインと語るサーバー(本当のドメイン名unknownつまりDNSで逆引きできない)から送信されたメールを削除する。

特定IPからの送信を拒否

特定IPからの送信を拒否するより、送信元のメールアドレスが自分で、送信元のIPが自分以外のものを拒否するほうが効果的だろう。このパターンも レンタルサーバサービスでは拒否方法が提供されていない。同様に、メーラーで削除設定してみよう。上と、同様に
 仕方ないので、メーラで受信後に自動削除してみよう。
 ツール→メッセージフィルタ→新規→フィルタ名を入力→条件でカスタムヘッダ「差出人」に「次を含む」・「自分のメールアドレス」とand条件で「Received」 に「次を含む」、「unknown」を指定し、 動作に「メッセージ削除」を指定する。 「Received」 に「次を含む」、「(unknown」を指定し、 動作に「メッセージ削除」を指定する。※2019/12/26更新 普通にサービスされている正式なものにも意外に送信元名が設定されていないサーバーがあるので、IP逆引きできないものに限定することにした。これだけでも半数以上のスパムを処置できそうです。

以上の設定で、かなりの数のスパムメールが減るハズ。
とりあえず、1週間くらいこれで様子を見てみよう

それってホントに電子マネー?知らないと損をする仕組み

本来、お金とは「 貨幣。金銭。また、財産。 」とか、特に知識がなくて扱えるもののはずなのですが、困ったことに電子マネーはだんだんとゆるゆるになってきて非常な危険を感じている人も多いはず。

蔓延している意外に短い使用期限

古くからあるSUICAは有効期限はありませんでした。長期間使用していないと使えなくなりますが、追加チャージすると復活するので、使用期限はないと言ってよいでしょう。しかし、最近増えつつある電子マネーやポイントカードは比較的短い使用期限が設定されています。管理データの大容量化もあってか、細かく取得が記録可能となりそれぞれの使用期限が細かく設定されています。細かい間隔でポイントの状態を確認しておかないと期限切れとなりポイントが喪失してしまいます。例えば、あるとき最短の期限を確認して、直近で喪失するものが1年後だったとしても、翌日に付加されたポイントの使用期限がその月の月末ということもありえます。損しないように込め間にチェックしないと…、なんとめんどくさい。
 いずれにしても、有効期限があって、気が付かないうちに喪失してしまうものを”お金”といってよいものだろうか? 常に気をつけておかないといけないものなんてなんと使いにくい仕組みなのだろう。

複雑すぎるポイント還元の仕組み

消費税還元のしくみ、どのような方法で、どのような仕組みで還元されるのか、何が、どのタイミングでどこに還元されるのか、個別ケースが多すぎて覚えきれない。これも、知らないうちにポイント喪失してしまう人が多数でてきそうな予感がする。たとえば、Edyの場合だけでもないかもしれないが、使ってから還元ポイントが付加されるまでに1か月くらいかかるものもあれば、もっとかかるものもありそう。そして受取期限が3か月くらいと短い。それから、コンビニ払いの分の還元がレシート上では還元される旨かかれているが、2か月以上たつのにされていないように見える..。 自販機で払った分はどうなるのだろう? ..消費税は込みのはずだが…..。 

努力の割には結局、誰も得していないような気がしてきた.. 

キャッシュレス化の推進のために 消費税還元 をやったことになっているが、得をしたのは電子化を進めている事業者?かと思われるが、現状は手数料なしで運用していて、来年6月以降で手数料を取るように切り替えるという。この電子決済を利用している事業者の話では、現在は現金と電子決済と同額に値段設定しているが、電子決済の手数料が有料になったときは電子決済の支払いでは手数料分だげ値上げするという。支払い方法によって値段が違うというのは違和感がある。しかし、通販を考えれば支払い方法によって値段が違うのはあたりまえと言えなくもない。そのように同じものに対して支払う金額が現金のほうが安いなら、現金に戻るのは当たり前にように思える。
 つまり、一見、電子決済の業者が得をしているかのように見える消費税還元も、得をする前に、敗退してしまいそうな予感がする。もしそうなってしまうなら消費税還元をうまく活用できなかった運用方法のミスと言えなくないが、、、。
 いやいや、レジの製造業者は売り上げを伸ばしていると言うかもしれないが、短期的に買い替えの時期がシフトしただけで、逆に売り上げに波ができてしまい商品サイクル的観点でロスが発生しているので、逆にコスト増になっているかもしれない。
 長期的な成長していくことを考えに抜いていないと誰も得しないものになってしまう。なんか最近そんなものばかりが目立ってしまうのはなぜだろう。

セキュリティパッチでないのに短期間でWordPress5.3.2がリリース。 5.2系のパッチは?

 WordPress5.3.2が12/18にリリースされた。 5.2.6はリリースされているかは自動適用されていないので不明。5.3.2での修正内容からは5.3.1で作りこまれた致命的なバグとわかります。これが短期間でのリリースの理由でしょう。ないことです。1件のバグ(#48145)は煮え切らない解析の結果、5.3での修正(#45821)の影響で発生していると判断して、修正を行っている。意外にPHP側に問題があり、その問題回避をしているのかもしれない。 いずれにしても、5.3.2は5.3以降に発生した問題の修正なので、これらの対処のために5.2.6がリリースされることはなさそう。  それから、 分かりにくいが5.2.5が登録されていた。  
 そのほか5.3.2リリースでは、5.3系のアップデートはこれで終わりで次は5.4とされている。なので、5.3系へのアップデートは様子見とします。
 ただ、5.3.1に上がってしまっている環境については、5.3.2にアップデートすることとします。

■それより、プラグインのパッチは?

 プラグインについては、当てられるものはパッチ適用する。

WordPress5.3.1 セキュリティパッチが出たけど、5.2.5が適用された。

 WordPress5.3.1 セキュリティパッチが12/13にリリースされた。 同時に、5.2.5もリリースされたようだ。5.2.5についてはセキュリティパッチのページには掲載されていない。5.2.5が適用されたことは期待値どおりだが、5.2.5のことが情報公開されていない点がいまいちだ。修正内容の管理も5.3.1は情報があるが、5.2.5の情報がない。相変わらず管理が不十分な感じはぬぐえない。

■で、パッチ適用はどうする?

 手動でのパッチ適用は、5.3.1しかできないようだ。これは5.3.に誘導する策略なのかと違ってしまうが、、、。 まずは、テストサイトで5.3.1の検証を行う。そこで、問題が無ければ、ほかの本番系サイトにも適用していく流れにするしかなさそうだ。…..  困ったものだ。

2019年 家庭菜園での収穫について

2019年は家庭菜園で多量のトマトの収穫ができました。来年はさらに収穫量というか収穫効率を上げたいので、その収穫効率向上の目標に向けて計画をします。そのまえに、2019年の収穫量について整理しておきます。

作物と各月の収穫量

作物金額合計6月7月8月9月10月11月
レタス450628.727.900.20.600
キャベツ207611.617.411.40.50.3
大根210611.711.700000
キュウリ441084.8229.924.326.42.20
ニンジン1715.71.24.50000
トマト11750108.829.668.64.34.71.6
ミニトマト2299525555621240304272177
トウモロコシ7907.92.23.62.100
ナス66711.37.91.4
21.521.5
合計49471

※個数は、スーパー等で販売されているサイズと同程度以上のものは1個とし、小さいものは重量ベースで小数点以下の数値としています。作業

投入費用と収穫額

まだ、ナスと大根は使い切りましたが、使い切っていない種もあります。とりあえず、全部使い切ったと仮定して、投入作業工数は無視して、回収効率を計算してみます。

作物投入収穫回収比率
レタス270450616.7
キャベツ32420766.4
大根54210639
キュウリ54441081
ニンジン2161710.8
トマト3401175034.6
ミニトマト3002299576.7
トウモロコシ2167903.7
ナス5466712.3

ニンジンの種は使い切っていませんが回収できていない。この回収率を参考に、新しいものも考慮して来年の作物を検討してみます。

太陽光発電のデータチェックをAI化

太陽光発電のデータを定期的にチェックしています。夜間だけ街灯を点灯するので夜昼の変動はありますが、これまで半年ほど一定であった電力消費がある時点から階段状に増加していることに気が付きました。調べると使用する必要のないポンプに電源が入れられ無駄な電気が使われる状態になっていました。これはもっと早く気づきたい事象です。
 以前、太陽光発電システムの故障を検知してメール通知する仕掛けを紹介しましたが、今回のような未知のパターンの異常は検知することができません。未知のパターンの異常であっても検知できる仕掛けであれば、今回の事象ももっと早く気が付くことができたのではないかと考えました。いわゆる今どきのAIの活用です。もっと的確に表現するとディープラーニングの活用です。この方法なら、以前に自動化した故障判断アルゴリズムもまとめることができるでしょう。
 ということで、太陽光発電のデータチェックをAI化してみます。