昨日の雷雨は、実測で5mmの降水量がありました。ここから5km程度離れている気象庁の測定ポイントでのデータは0mmでした。かなり激しい雷雨だったので広範囲に降ったように感じましたが局所的な雨でした。
4月以降の気象庁の降水量のデータは、実測データとほぼ一致していたので気象庁データで十分そうだったのですが、昨日の降水量データの5mmと0mmの違いは大きい。自動化するなどの元データにするには、もう少し正確なデータのほうが良いような気がするがどうだろう。
局地的なデータを取得できる何かいい方法など、コメントをお願いします。
連休中に、予定していた苗の植え替えは完了
残っていたトマトの苗を植え替えました。まだ育ちがいまいちのものはポットへ植え替えました。これで当面、急ぎで植える必要があるものはなくなりました。そして、今日は予想以上に雨が降りました、直近の水の心配も解消です。
トマトの苗を植えるために、いったん移動した土を戻して新たに畝を作りました。その際に、除去したはずのスギナの地下茎が多数見つかりました。先日見つけて除去した分の半分くらいを除去しました。この分だと、先日除去したのと同程度の量の地下茎が残っているものと推測される結果です。今回作った畝の状況も今後確認していきます。
リーフレタス植え付け
今日は土が乾いてきたので、残り半分の畝つくりから植え付けまでを行います。
今日はスピードアップのため根っこの除去レベルをさらに変更、根っこをカテゴリ分けして対処方法を設定します。木の根っこは見える範囲を除去し、深く追わないことにします。地下茎については追えるところまで追ってとことん除去します。
細かい根っこは無視して、気になる根っこだけを除去することにします。地下茎の主なものはスギナです。地下茎の先を追い始めると50cmより深いところまで垂直に伸びているものもあります。スギナさえなければ作業がはかどります。
前述のレギュレーションを設定後すぐにスギナの巣を発見しました。レベルを変更したらスギナの巣にぶち当たるのがジンクスな感じがしましたが、この巣も5,60cmくらいまで追っかけて除去しました。
さて、このレベルでどの程度で雑草が生え始めるのか確認していきます。ちなみに、上下ひっくり返しただけで根っこを 除去しなかったら1か月ぐらいで雑草が生え始めています。一番生えてきているのはスギナです。そのほかの雑草も生えていますが、 スギナの比ではないので、スギナ中心の除去対処でよかったのかもしれません。ひっくり返す際に地下茎を細かく切断して地表近くにもってきたが発見できていないものがどのくらい残っているかが今後の手間を左右しそうです。今回以上に対処は、すべての土を篩いにかけるくらいしかないと思います。
何か月か、今回作った畝の状況を確認していきます。
脆弱性情報の収集
脆弱性関連情報を「定期的に自動チェックしてメール通知するとか、検討してみよう。」ということで、とりあえずクラウドサーバ上にpythonコードを移行し、定期実行の手順を検証します。
phpから呼び出したところで、エラー。このクラウド環境は、Python2が動いていて、python3には対応していない。いまどきのクラウド環境ならPython3に対応しているのだろう。つぎの引っ越し先はPython3にも対応していることを条件に入れよう。その選定作業は別途行うことにします。※
Python2用にコードを書き換えて、チェック対象のコンテンツをダウンロードできることを確認できました。
つぎに、クラウド環境のコントロールパネルで定期実行タスクを設定します。
定期実行で、「with open(saveFilePath, ‘wb’) as saveFile:
IOError: [Errno 13] Permission denied: 」のエラーメールが送られてくる。
phpから呼び出した時とは実行ユーザが異なることが原因だろう。
ということで、パス指定を修正して、定期実行によりチェック対象のコンテンツをダウンロードできることを確認できました。
次は、脆弱性関連情報をチェックするPythonコードを用意します。
久しぶりの晴れ、キャベツは順調
雨の後のため地面は湿っているので今日はほかの作業をすることにした。先日植えたキャベツは順調そう。２つのレベルで根っこを除去したので、この後それぞれどの程度、スギナなどが出てくるのかチェックする。
パワコン？謎の消費電力増加 その3
先に「昼と夜の消費電力の差は、時刻によって切り替わっているだけと判断できます。このような動作が想定されるのはパワコンです。次回以降パワコン観点で検討を行います」と書きましたが、今回はこの点について確認してみます。
まず、なぜパワコンに着目したかですが、このサイト2では、1台の”KP55M-J4-SS”（パワコン）を使用しています。このパワコンの仕様として「 消費電力（夜間（交流側）） 0.5W、11.5VA（Typ.）」の記載があります。
http://www.solar-frontier.com/jpn/residential/products/pdf/discontinued/KP55M-J4-SS-A_KP44M-J4-SS-A.pdf
また、パワコン自体の表示器が、昼間は発電量が表示されているが、夜間は表示が滅灯し明らかに昼と夜で動作状態が切り替わり 消費電力量も変わっていることがわかります。
つぎの情報を見ると、パワコンの機種は違いますが、表示を滅灯したときより点灯したときの消費電力が大きいこともわかります。
http://www.faq.energy-innovation.omron.co.jp/print/faq/9
このグラフから、夜間の消費電力は0.26kW、昼間の消費電力は0.17kWで、その差は0.09kWつまり、90Wの差があることがわかります。
パワコンの使用に書かれた消費電力とは2桁ほど違っているので、本当にこれがパワコンの消費電力なのかは疑問です。 そこで、昼間から夜間の消費電力に切り替わる時刻がどのように推移するかを確認するために日ごとの18.19,20,21時それぞれの消費電力量をプロットしました。
この結果から、昼間から夜間の消費電力に切り替わる時刻は日々徐々に一定に変化しており、日没時刻から算出したと推測します。このような挙動をするのはパワコンなど太陽光発電システムくらいしか思いつきません。 パワコンの消費電力は0.5Wなのか、90Wなのか、パワコン以外に夜間電力消費が発生するものがあるのか確認してみます。
ここまでの状況から、電力量が大きいかどうかの確認は必要だが、パネルが故障するなど、長期間発電量がゼロの場合、パワコンが無駄に電力消費するということがわかりました。発電システムの故障を検出したら、放置せずにすぐに修理するとか接続を切るとか処置をするべきでしょう。放置や変な処置をすると、淡路の風力発電のような事故につながるかもしれないので故障を早期に気付ける仕組みも重要そうです。
パワコン？謎の消費電力増加 その２
「サイト2の夏の冬の消費電力で夕方は日照時間の影響が見えるが、朝方はずれがないように見えています。データの整理ミスの可能性が一番高いと思い再点検しましたがここでの間違いはなさそうです、これについても原因確認していきます」と前に書きましたが、今回はこの点について確認してみます。まず、考えられる原因について検討してみます。
①どこかの時点でデータ収集する時刻がずれた。集計ミスではなく機器の設定の問題を想定しています。
②天候の影響で、たまたま6月の該当日は早朝の日照がなかった。
③ ①、②のいずれでもない。パワコンなどの負荷側の挙動で発生している。
①の確認のため、別の日のデータをプロットしなおしました。6月、12月のデータは2013年分で、6月の2としたものは2014年4月分です。
2014年4月分でも夕方の消費電力の増加時刻の差が確認できますが、朝方の減少時刻には変わりがありません。このデータの日の気象庁データは快晴で、天候による朝方の減少時刻への影響はありません。念押しで、12月のかなり強い雨日のデータに変えてプロットしなおしました。
意外に朝方の減少時刻だけでなく、夕方の増加時刻にも影響はありませんでした。この結果からサイト2には日照により点灯・滅灯する機器の影響ではないという結論にたどり着きます。つまり、①、②ではないということです。昼と夜の消費電力の差は、時刻によって切り替わっているだけと判断できます。このような動作が想定されるのは③のパワコンや太陽光発電システムです。次回以降パワコンなど太陽光発電システム観点で検討を行います。
WordPress投稿のパスワードって何？ まとめ
まるめると「投稿ごとにパスワード設定可能なユーザIDが共通のフォーム認証」ということです。Webエンジニアならこの表現で大体の挙動は理解できると思います。
Web技術的な表現で書くと、次の通りです。
・WordPressで共通のポストデータでパスワードを指定する ユーザIDの指定がない フォーム認証。
サイトで固定のクッキーを使っているのか、それともページごとに指定するクッキーで指定するのかと推測しましたが、パスワードをWordPress固定のポストデータで指定して、WordPressのクッキーでセッション維持をしていました。
これにより次の動作をします。ある投稿のパスワード入力フォームに別の投稿用のパスワードを入力すると、パスワードを入力した投稿は参照できないが、パスワードが一致した投稿は参照できるようになる。また、ある投稿Aを参照できる状態で、別の投稿Bを参照するためのパスワードを入力すると投稿Bは参照可能となると同時に投稿Aは参照できない状態に変わります。
結局、この機能、どこかで投稿参照用のパスワードを利用者に渡して参照可能にするというものでしょう。 実際に使っているというか、有効に使えているところがあるのでしょうか。
WordPress 投稿の非公開ってどう使う？
この機能って、公開、非公開をあとで切り替える機能ってこと? つまり、主な目的は公開済みのものを後で削除ではなく非公開に切り替えるということ？ 見せないようにするのに削除するのではなくスイッチを切り替えて見せないようにする。証拠保存が目的でしょうか？
非公開にすればタイトルさえ表示されなくなる。
機能名が、なんか変。 つまり「公開する」なのに「非公開」ってなっている点です。日本語に翻訳したところで変なことになっているのか？
やっぱり読み通りでした。英語だと、
「公開する」→Published
「非公開」→Private
です。
「私的：Private（プライベート）」の反対語は 「公的：public（パブリック）」なので、英語だと違和感がありません。 Privateを日本語に翻訳するときに”非公開”としたことで、機能名的な違和感が発生したわけです。