2018年9月

　台風２４号の接近で出かけることができないため自宅で掃除やメンテナンス作業に専念することにしました。Ubuntu, ethOS, Win10で切り替えていて気になっていた表題の時刻連れ(UTC – JSTの9時間きっかりずれる)対策について調べたところ以下のページがヒットしました。
Linux_Windowsデュアルブート環境時における時刻ずれの解決(http://d.hatena.ne.jp/gin135/20140304/1393943319)でWindows7向けに書かれているコマンド

reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 1

をWindows10 Pro 1803の管理者権限付きコマンドプロンプトで実行したところエラーにならず、再起動も兼ねてもう一通りOSを切り替えても時刻がずれなくなったのでWin10でも有効と思います。
　デュアルブートに限らずUSBからでもLinux系のOSを走らせるとCMOS clockにUTCの時刻を書き込み、その後に起動したWindowsがそれをJSTとして読み込むようなのでレジストリにCMOS = UTCとしてWindowsの設定を変更するこの対策方法で私は問題ないと思います。再インストールやVer.upを繰り返すLinux等で対応するのも面倒すぎるというのが大きいです。仮に戻す場合は

reg delete HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /f

で追加した設定を削除することで戻せるようですけど必要を感じていないので実行していません。

　後日追記)Windows10でのNTPクライアント設定(W32Timeサービス)についてはRaspberry Pi Zero WHでAE-GYSFDMAXBを使用したgpsd+ntp server(https://kadono.xsrv.jp/2019/02/11/7939)に書きました。

　台風接近で非常に忙しい休日になりました。朝から荷物を受け取り説明書を読む時間もなく最初にカメラ側の電池が切れていることに気づくまで時間がかかりました。出先の待ち時間で説明を読んでFLIR ONE Pro本体に充電して電源を入れてからZE520KLに取り付けると動くことに気づきました。ZE520KLよりもずっと高価なモジュールですので一瞬困りました。
FLIRでの走行後プリウス画像。
　どこの温度が高いか簡単に分かります。エンジンルーム、ダッシュボード付近、フロントブレーキディスク、リアブレーキドラム、補機バッテリ…。車体下の高温部分は排気管からの赤外線を水たまりが反射していると思います。また、補機バッテリの付近も温度が高いですけど樹脂製のリヤバンパーで赤外線が遮断されているらしくクォーターパネルの鉄板部分だけ温まっているようです。一方でフロントバンパーが温かいのはラジエーターのせいでしょうか？
可視光での近況(ZE520KLで撮影)
同価格帯のIronWolf 12TB ST12000VN0007のHDDとどちらを買うか迷いました。放射温度計では把握しにくい面での温度変化が一目瞭然にできるのと、従来品や現行廉価版LTの温度範囲-20° ～ 120°を超えブレーキディスクなども測れる-20° ～ 400°に対応していることからプリウスの熱解析とは別件(NVIDIAヒーターからの発熱解析)を主な目当てに購入しました。が、車両の温度分布確認にも十分使えそうです。台風前でバタバタしていてプリウス正面やハロゲンランプ、マフラーなどの温度は未確認です。購入初日の感想としては使えそうですが、マニュアルがやや不親切なのとUSBコネクタでの固定が不安定なのが少し不安です。
以下おまけ、

アプリを起動したら最初にこんな画面になって驚きました。ボタンを押しただけではダメでクイックスタートガイドを読んで"まず充電"したら使えました。

　このサイトの使い方で直接影響する項目は無さそうですけど、不具合修正が中心ということで念の為WordPressのテーマLuxeritasを3.3.2から3.3.3へアップデート作業を行いました。詳細は開発元のLuxeritas 3.3.3 リリース(https://thk.kanzae.net/wp/release/t6147/)を御覧ください。

　先週のブラウザキャッシュ設定ONへの変更でサイトの確認などで繰り返し読み込むときにはかなり速くなったと思うのですけどChromeのメモリバカ食い度も悪化したような気がします。現行のDDR4 PC4-21300 4GB*2から8GB*2に変えるにしても去年の夏ぐらいの水準まで値段が下がらないと厳しいです。

　ちなみに、昨年末から使用しているメモリCMK8GX4M2A2666C16の対応規格自体はDDR4-2666(PC4-21300, 1333MHz)対応ですが、通常はDDR4-2132(1066MHz)で動作させています。CPU-Zで確認してみたところ以下のような感じです。

　連休前には復旧するかと思っていましたけどR162深見峠が通行止めのままでした。北側から回り込んで到着。普段はズラッと並んでいるはずのオートバイが一台もなく、一瞬平日か？と思いました。乗用車はそれなりにいましたが例年と比べると閑散としていました。
近況。
　普段はオートバイやら乗用車やバスで混雑して停めにくい場所に余裕で停められました。休憩していたらオートバイが一組(３台？)だけ来ました。上の写真、プリウスの屋根の向こう側自販機小屋の前辺りにヘルメットが写っていると思います。
　後日追記)次の連休までには深見峠の通行止は解消したようです。ただ、9/23時点で片側交互通行は残っています。

　昨晩の帰り道、前の車に続いて普通に走っていたところいきなり猫(たぶん)が飛び出して猛スピードで横断していきました。あまりの勢いでほとんどブレーキも踏めませんでした。ドラレコからSDXCカードを引き上げてきて調べたところ以下のような状況でした。
左側の白線から飛び出そうとしています。
この時点では見えませんでした。
いきなり目の前に飛び出てきました。
これぐらいのタイミングで急ブレーキを掛けはじめましたけどすぐには減速しません。
あっという間に対向側へ走っていきました。
通り過ぎてからようやくブレーキが効き始めましたが続けて他の動物が出てくる気配もなくブレーキを解除しました。後続車には何があったか分からなかったと思います。

　しばらく放置していたKindle Voyageのバージョンを見たところ、いつの間にか5.9.7まで自動でアップデートしていました。7月の更新なので8月は無かった?ようです。
5.9.7での新機能
ZE520KLの更新も同様ですけど”パフォーマンスの改善とその他の機能強化。”が何を指していのかはさっぱり分かりません。特に新機能は使っていません。が、本の一覧表示をスクロースする動作が少しスムーズで速くなった(以前は結構引っかかった)気がします。ただし、ハイライトのための文字列選択動作が遅いし中々思い通りに選択できないのは変わらずです。
　縦書きの文庫本などは特に電子ペーパーがLCDよりもずっと読みやすいと思います。この端末は2015年6月購入で3年以上経ち既に現行機種ではなくなっていますけど現行のKindle Oasisは値段が高すぎると思うので当分買い替える予定はありません。

　このサイトを置いているレンタルサーバー会社さんから従来の10倍以上のアクセス処理性能！Webサイトの高速化・同時アクセス数の拡張を実現する「Xアクセラレータ」機能提供開始のお知らせ(https://www.xserver.ne.jp/news_detail.php?view_id=4753)というのが届いたので設定してみました。

　が、タイトルの通り失敗しました(原因は追記参照)。トップページは問題なく表示されましたけど比較的アクセスが多いcategoryや過去記事へのリンクなどがすべて404になり大急ぎで切り戻しました。さらに困ったのが設定メニューでOFFにしただけでは404から回復せずバックアップしておいた.htaccessを上書きしてようやく復旧しました。

　代わりというか、上記XアクセラレータをOFFにしようとしたところONにした時点で先週お知らせが来ていたExpiresヘッダで表示速度を向上！「ブラウザキャッシュ設定」機能提供開始のお知らせ(https://www.xserver.ne.jp/news_detail.php?view_id=4744)の機能も有効になっていたらしくOFFへの設定変更反映待ち(最大15分らしい)になっていました。改めて説明書きを読んでこちらの機能だけならばヘッダの送信だけで.htaccessを破壊することは無さそうですし、破壊しても再度上書きするだけなのでブラウザキャッシュ設定のみ推奨のすべての静的ファイルに適用しました。.jpgが多いのでそれなりに効くと思います。

というわけで、本日の設定変更は上記画像のブラウザキャッシュ設定のみにしました。

　翌日追記)この件についてメールが来ました。内容はほぼ本日PM3:40～PM10:10までのXアクセラレーター機能における特定条件下での不具合について(修正済み)(https://www.xserver.ne.jp/information_detail.php?view_id=4754)の通りでこのサイトは特定条件に当てはまったようです。.htaccessのコードなど(すべてコメント内のため)気にしていなかったです。念のために切り戻し用に保存したファイルを確認したところEUCでした。UTF-8ならば問題なかったらしいのでUTF-8N(BOM無し)に変換した上で再度上書きしました。正直、コメントの文字コードで挙動が変わるほうがおかしいです。

　よって、不具合が直ったと連絡されても不信感は拭えないためXアクセラレータの利用は当分見送ります。ついでに書くと、不具合動作時にキャッシュで404になった分のログが無かったのでキャッシュ分のログはもらえない(.jpgだけ持っていくようなアクセスが記録に残らない)懸念も残っています。

　非常に素早い対応には感謝しています(404の異常な多発で事故に気づかれたか？運用の監視能力は良さそうです)。ただ、新設定はもう少し検証してからリリースしていただきたいです。

　既に現行では古いモデルになっているはずのZE520KLに最近はよくアップデートが降ってきます。帰宅してから画面を見ると以下のお知らせが表示されていたのでVDSL回線に繋がっていることを確認してダウンロード。

あいかわらずシステムパフォーマンスやGoogleモバイルサービスが具体的に何を指しているのかは不明ですけどセキュリティパッチだけでも更新する必要があると思いますのでとりあえず更新しました。

更新作業は成功したようです。が、ここ最近の更新は毎度ですけど特に変わった感じはしません。ひょっとしたらETWSなどで変更が入っているのかもしれませんけど深く調べている時間もありません。

　自転車に乗っていた頃は帰りに渡月橋を渡って走っていた時期もありました(このサイトを”渡月橋”で検索すると2007年ごろの記事がでます)けど、ここ10年ぐらいは人混みを避けるためもありプリウスでは走っていませんでした。昨日の京都新聞の記事嵐山・渡月橋の欄干損傷少なく　京都市調査、復旧時期未定(https://www.kyoto-np.co.jp/local/article/20180906000152)の写真の通り東側の歩道が塞がっているだけで車道は通行可能のようで北から南へ走ってきました。
渡月橋交差点、左折で橋を渡ります。昼間の右折は自転車でもやめたほうがいいと思います(路線バスは問答無用で突入しますけどノロノロになります)。
左(下流)側の歩道が通行止めで欄干が倒れていますが橋梁本体は無事なようです。右(上流)側の歩道は人が歩いていました。
このあたりで中央でしょうか。
南詰へ渡りました。そのまま直進すると狭い区間があり路線バスと離合困難です。この辺りの道を知らない方は駅の方へ回ったほうが無難かと思います。しかし、地元車両も私もいつも通り対向車に加え自転車や歩行者にも注意しつつ狭路の方を通過しました。

　台風21号の接近で出勤したと思ったら即帰宅指示で帰りました。PCのデータでも片付けたり下書きのまま放置している記事を処理しようと思っていたら午後になって突風が吹き荒れ14:00ごろには瞬断が連続しました。auひかりのVDSL回線が14:30頃の少し長い(数秒？)瞬断の後から通信不能となりモデムの電源をOFF→ONしても赤ランプのまま復帰しませんでした(建物ごとダウンした模様です)。幸い完全に停電したり携帯のLTE回線はdocomo/au共に切れなかったので固定回線(巻き添えでauひかり電話サービスを使った固定電話)だけがダウンしました。UPS無しでのデスクトップPCでの作業継続は危険と判断してシャットダウンしました。
　あちこちで停電などが多発していたようですし、固定回線が落ちただけで携帯回線でバックアップできていたのでジタバタせず復帰を待つことにしました。
翌日追記) DynamicDNSサービスのメールによると
Connection lost: 2018-09-04T14:30:08+0900
Connection resumed: 2018-09-05T14:09:22+0900
のほぼ丸一日ダウンしていたようです。