ゆうはるのブログ

某EVメーカーが自動運転年内完成といっているらしい。ここでこの記事は何年の記事だっけと思ったかたもいるだろう。というのもこのメーカー、これまでも何度となくもうすぐリリースを言い続けて、その都度なんのコメントもなくなかったことにしてきている。コンピューターやセンサー類の進歩からするとそろそろ一定条件下での完全自動運転が完成してもおかしくないような気がするが、ブログマスター的には再度無かった事になるとみている。

というのも、そもそも自動運転の完成とは何を意味するのかが明確にしていないからである。ブログマスター的には自動運転をリリースするためには精度以前に、搭乗者が法律を犯すことなく移動でき、事故した際の責任からも解放されるというのが最低限必要な条件であると考えている。それができているなら多少精度がいまいちでも完成したと言える。つまり某ＥＶメーカーのすべきことは行政と保険屋に働きかけて完全自動運転車の認証条件を決めさせ法律を改正させ保険屋と交渉して事故時に保険がきくようにすることなのだ。そうでなければ完成したとメーカーが言っても絵にかいた餅でしかない。

そこまでメーカーに求めるのは酷だという方もおられるだろうから年内に完成するのは十分な精度を持った自動運転機能だとして考えたらどうだろうか。その場合でもやはりこれまで通りなかったことにされるだろう。というのも結局十分な精度というのが決められないからだ。というより十分な精度を決めるために必要なのが法律の定義と保険に加入できる条件であるといってよい。

当初某EVメーカーは自動運転なんて簡単にすぐできると考えていたと思われる。そのため定義なんて決まってなくても信者のようなユーザーに使わせて浸透させて社会問題化してしまえば法律や保険は後追いで勝手に整備されると思っていたのだろう。その時期からもう何年もたっているのだからそろそろ現実路線への着地を検討（行政、保険との折衝）してもよいと思うのだがそこはCEOの性格的に難しいのかもしれない。

某メーカーが自動運転がもうすぐ完成すると言い出してそろそろ7年くらいたつのだろうか年内完成を楽しみに待ってみよう

中華バッテリーを取り寄せて交換したGarminのランニングウォッチだが、期待していた稼働時間の延長がなく、もう思い切って新型を購入しようかと迷い始めていた。ガラス面の裏の黒い塗料が一部剥がれかけていて見た目が悪くなってきているのも理由の一つだ。しかし容量偽装の販売者に一矢報いたいと思いクレームを入れてみることにした。久しぶりに使う英語は単語をいろいろ忘れており大変だったが何とか伝わったと思う。どうせ何も返信ないだろうと思ったが、返信があり、「初期化して、２，３度充電してみろ」というような返事が来ていた。時間稼ぎか？と思ったがせっかく返事が来たので試しにやってみることにした。どうせ、電池交換前の無限再起動トラブルで初期化しているので失って困るデータはないし初期設定の仕方もまだ記憶に新しいから簡単にできる。ということで満充電からの稼働時間を計測してみた。（計測と言いながらかなり適当です。容量2.5倍の計測だから雑でもはっきり延長したとわかるはず？）

元の稼働時間を正確に測っていないのだが、大体、普通に使っていて一日10数％の消費、GPSモードで1時間10%の消費だったと思う。

とりあえず、一日目　夜にGPSモードで時計を放置。（腕につけているのと違うから比較対象としてよいかは不明だが）朝起きてみると50%弱だった（適当すぎる？）11時頃にスタートして7時にストップしているので大体8時間。8時間で50%。初期化前に同じ条件で確認していないが、GPS1時間10%とすると8時間で残り20%予想だから延長しているかもしれない。

もし初期化で持ちが変わるとするなら何が理由として考えられるのだろうか。電池の残量を単に電圧を見て決めているならこんなことはあり得ないはずだ。自分がソフトを作るならどうするだろうかと考えてみると、

新しい満充電容量　＝　充電時間×充電電流／(100%-充電開始時SOC)　×　100
（充電電流は既知とする）で満充電容量を推定して、古い満充電容量と足して２で割るとかとして決定し、SOCの減らす方は電圧ではなく、使用しているモード毎に電流値を決めておいて減らしていくということをしていることになる。たしかに単に電圧で見てしまうと充電を電圧が上がった後一定時間CV充電してないと充電完了直後に100%から下がってしまう可能性があるため回避策として導入していてもおかしくない。こんな時計にそこまで面倒な処理するか？とは思うが、Garminは航空機向けGPSなどもやっているため満充電容量推定とSOC推定と低電圧警告、低電圧シャットダウンを組み合わせている可能性はあり得るのかもしれない。
結果を楽しみに数日間楽しませてもらうことにする。

最近、ハリーポッターの続編？のファンタスティックビーストなんとやらの映画をみた。正直、ハリーポッターも最後のほうはだいぶいまいち面白くないというか始めてしまったから仕方なく最後までやりました感のある映画になっていたような気がしていた。ロードオブザリングもそういうところはあったが幸いあちらは映画界の伝統？の3部作で止めておいたためマンネリ化は避けられていたのではないだろうか。そこに加わったのがファンタスティックビーストである。一応ハリーが使っている教科書を書いた人が主人公だったり、関係者が周辺キャラに登場するということではあったが見ていてもあまり面白いと思えない（サブスクでみたのだが）。途中で寝ないで見るのが困難なくらいであった。妻は頭が柔軟なのかそれなりに楽しんでいるらしいが自分にとって何が問題なのか考えてみた。

思い返してみるとそもそもハリーポッター自体言うほど面白くなかったような気がする。よく言えば世界観が広いだが、悪く言うと毎回毎回新しい設定を作る場当たり的な小説だったような気がする。これはもともと第一作は子供向けの短めの小説だったのを売れたから続編が出たことを考えると事実場当たり的だったのだろう。つまり作者にここまでの大きな世界観を持った面白い小説を書く才能は無いのではないかと思うのだ。毎作毎作ページ数が増える一方の小説。作者の自己満足部分が多くなって小説の面白さのために削る、推敲することができてないだけではなかったかと思う。第一作は小説を見てもらって発売してもらうために子供向けに内容を絞って作ったから良かったのではないか。それが売りて市場になったとたんに元の売れない小説家の癖が出てしまったということだと思う。

ファンタスティックビーストは原作が売れない小説家が書いているから面白くないと言ってしまえば一言で済むのだが、あえて原因を書き連ねてみたい。

まず、映画の目的がわからない。主人公は幻想動物を保護？もしくは調査している人という設定である。で映画のストーリ的な目的地がわからないまま話が進み、世界観の説明というか自己主張が延々と続く。世界観の説明というのはメインストーリを進めながらさりげなく入れていくものだと思うのだが、この映画の場合、世界観の説明が映画のメインと化している。元の小説の出来が悪い（遂行できていない無駄に長すぎる小説）だからだろうがこれを面白いと思えるのは幻想動物を見るだけで楽しめる子供かハリポタ信者のみではないか。原作者が勝手に作った幻想動物の特異な生体を物語のカギにされても「ふーんそうなんだ」くらいの感想しかない。他の小説、映画でもそういった独自設定がカギになっていることは多々ある。しかしその場合独自設定はメインキャラ数人にあり、その独自設定を生かす話があちこちにあって、そのうえで物語の重要なカギであることを気づかせずに最後まで引っ張るわけだ。観客は最後にそれに気づいてハッとするから面白いのだと思うが、ファンタスティックビーストにはそれがないというかそもそも映画的にサブのサブでしかない幻想動物の生態なんかどうでもよいって感じなのだ。

そもそも幻想生物の研究者が悪者と戦うという設定が無理があるのではないか世間で認められていない幻想生物の研究をしたい学生が学校を卒業して教科書になる本を書いて世間で認められるまでの話を書いた方がよほど面白かったのではと思う。それがハリーポッター一作目の面白さでもあったのではないだろうか。

最近Windowsでバージョンが上がると遅くなるのが当たり前と思い込まされていたのだが、Ubuntu20をUbuntu22にしたらよりきびきび動くようになって驚いたという話。どうやらトリプルバッファリングが採用されたらしく、その関係でいろいろ最適化されたのかも。もともとWindowsよりよほどきびきび動いていた（アンチウィルス無しだが）。実際仕事で使う上では不満がほとんどないし、GUIの出来も必要十分という感じでいっそUbuntu一本にしようかと思っていたほどであるがプリンタの対応、開発環境（VisualStudio）がWindowsのほうが便利。という2点で併用する形になっている。

ではなぜUbuntu20のＰＣを持っているのかというとWebサーバーアプリの開発環境としてである。安くサーバーを立てたければLinux系一択であるため開発環境は自動的にLinux系になる。Dockerにしたらとも思うのだが、現在のところサーバーをDockerで構築するつもりがない（なんとなく遅くなりそう。ならない？どうなのそこのところ）ためローカルで設定スキルを練習したいためUbuntuを使っている。開発環境ではあまり印刷することがないため使っていて困ったことはない。それどころか日々安定性を増すUbuntuに驚くばかりである。特にGPUの対応が良くなってきているのがすばらしい。Ubuntu20の唯一の不満？は重い処理をしているときに目に見えてマウスの反応が悪くなるところだった（GUI用に少しCPU処理能力を残しておけばよいと思うのだが）

MACで文章書いているみたいな人がいたら正直無駄だからUbuntu買ったほうが良いと思う。最初の一台がUbuntuだったりChromeOSだったりしても全く不思議ではなくなってきたなと思ったのであった。

ガーミンの交換用として購入した中華電池が到着した。カタログスペックではオリジナル電池の2倍以上だ。（180mAh→500mAh）交換はYoutubeを見てやったのだが、コネクタを外すところで油断して基盤側のコネクタを破壊しそうになった。電池は同じ大きさ、同じコネクタなので前面ガラスさえ割らずに外せれば後は楽勝とか思っていたのが良くなかった。交換して充電してみたがどう考えても500Wh の容量は無いような気がする。持ちを図ったわけではないのだが、夜100%に充電して朝に93%になっていたから交換前の電池と変わっていないのではという気すらする。Liイオン電池は最初と最後の電圧降下が早い特徴があるからもしかすると中間部分の容量が多いという奇跡があるかもしれないが、40%から充電した時の数値の上がりの速さからするとそれもなさそうな気がする。苦労して材料揃えて2倍の持ち実現と思っていた反動か、がっかり具合も半端ない。勢いで新型買ってしまいそうだ。とりあえず0%になるまでの日数を確認はしてみるけど。5年経過しているのだから同じサイズでも2倍の容量あるかと思ったけど電池の世界はそうではなかったのかな。充電で爆発しなかっただけましと思おう。

コントローラのドリフト現象を修理してから急に出番が増えた我が家のスイッチであるが、久しぶりに家族でマリオカート８をやってみた。というのもXBOXのGAMEPASSにマリオカートもどきのゲームが入っていてやってみたら出来がいまいちで本家をやりたくなったからだ。XBOXGAMEPASSのラインナップに言いたいことはいろいろあるのだがそれは別の機会としてマリオカートの出来は本当に良い。そもそもスイッチより圧倒的にハイスペックのはずのゲームPCなのにかくかくしか動かないマリオカートもどきの出来と比べてスイッチのスペックでなめらかに動くマリオカートは本当に素晴らしい出来といっていいのだろう。

で、本題なのだが、コース選択をしていると見慣れないコースを発見したのである。こんなコースあったっけ？と思ってみてみると追加DLCらしい。マリオカート８をを購入したのはずいぶん昔のことなのに今更追加DLCなんて珍しいと思ってよく見ると2023年12月までに順次コースが追加され、全部追加されるとコース数が最初の２倍になるらしい。マリオカートは多彩なコースが売りだからコースが2倍になるということは実質マリオカート９が出るようなものである。これで2500円なら高くないということで購入してみた。幸いすでに16コースはリリース済だったので結構楽しめたが、あと一年以上少しずつリリースって気が長い話で任天堂だから安心して購入できたが、ほかのメーカーなら一年以上長いリリース計画のDLCなんてとても買えないだろう。

任天堂もいよいよこういう商売するようになったかと思うと不思議な気持ちになったのであった。

ちなみに追加コースの出来は、そこまでやりこむタイプではないので細かいところはわからないが楽しめたので良いのではないだろうか。一つ気になったのはところどころ処理が重いのかカクカクするところがあるというところだろうか。これは次のリリースで改善されるのか、古いスイッチだから仕方がないのかわからないが、ドリフト現象が一向に直る気配がないことといい任天堂にしては珍しいと思った。

ある日、子供のかけっこ教室に向かう車の中でのことだった。ふとガーミン（5年ほど前に購入した735XTJ）を見ると画面がおかしい、というか、どんどん画面が消えていっている。一瞬自分がフリーズ仕掛けたが、とりあえず電源強制オフ→オンを試してみると画面が表示された。ところがそこから知らないうちに勝手にシャットダウンするなどいよいよもうダメかと思わされたのだが、データリセットやらなんやらしていたら直ってしまった。

復活したはいいがバッテリ持ちが早くなったような気がして（買い替え正当化のための気のせいかも）買い替え時期なのかと後継機種を物色し始めたのだがやはり結構高い。もともと5万近くで購入しているから5年で買い替えだと毎月1000円弱となってなんか割高感を感じる。GARMIN以外の機種で安いものはないかと探す日々だったが、最近のスマートウォッチは有機ELばかりでGarminの常時表示の反射型液晶になれた自分からするとちょっと物足りない。（解像度は有機ELのほうが高くて室内での見栄えはいいのだが）Garminのエントリーグレードでも自分の時計より電池持ちはいいけど、せっかく買い替えるならGPS精度や血中酸素が図れるハイグレードが欲しい。しかしGarminのそのスペックのものと他社の同等スペックだと数万違う。電池交換でもよいが、Garminに頼むと結構高いし、交換しても最近の走力ではウルトラ走りきるまで持つか微妙だ。いまのエントリーモデルなら20時間以上持つのにだ。電池交換で最新の大容量電池に変えてくれるならそれでもいいのにとも思っていた。そこでふと、ガーミンの電池って自分で交換できないのかと思いついた。自分で交換できるなら容量アップ電池に交換もできるかもしれない。どうせ買い替えるなら失敗してもそれほど痛くないし。

そこで探してみるとやはり本場？中国のサイトにはあるはあるは、電池だけでなく、前面の液晶＋ガラスもあるし、背面の樹脂の筐体もある。ちょっと探せばマザーボードすら出てきそうな勢いだ。自分の735XT用は少ないが、同時期に発売された235用がかなりの数あり電池交換動画を見たが内部構造は同じで液晶サイズ、解像度も同じだから困ったら235用に交換しても大丈夫と思われる。もしかしたら今回電池を交換して次の5年後くらいまではまだ予備部品が手に入るのではないかと思う。ちなみに電池は450mwhでGarmin735用となっているものを選択した。正規品の容量は180mWhらしいので2.5倍あることになる。多少スペックに偽りがあったとしても2倍は固いとすると最新機種と同等の電池持ちになる。スペックが向上するとなると現金なもので急に今のGarminがかわいくなってくるから不思議だ。交換は前面ガラスを温めて外すという未経験のやり方だから不安だが、電池にある程度の道具はついてくるし、接着剤や両面テープは注文したからゆっくり丁寧にやればできるはず。GPS20時間超えのスペックが手に入るかと思うと今からワクワクするのである。

なぜかGhostScriptをビルドしている。文字化けは改行コードの取り扱いではっせいするんだから、そのあたりの変換コードをコメントアウトしてみようじゃないかということである。じつはこの前にＣ＃でPDFを暗号化してくれるフリーのライブラリを試してみたが、同じ現象だったためおそらくフリーのものはどれもGhostscriptを内部的に使用しているのではないだろうか。とすると文字化けさせないためにはadobe製品を使用するしかないということになる。一か月くらいはお客様にごめんなさいで行けないこともないと思うがずっとこのままというのは困る。ビルドはホームページ？の説明がVisualStudioのものすごく古いバージョンで書いてあってその通りに実行したら即座にエラーがでるなどかなりやばいと思ったが、makeファイルの中をのぞくとVisualStudio2019にも対応していて単に2019の最新アップデートバージョンに対応していないだけだったのでちょこっと修正するだけでビルドしてくれて安心した。途中で各国のフォント名を書き連ねたソースファイルが文字コードの問題（またか！！）でエラーになったが、その部分だけエディタの自動変換で変換してUTFで保存したらコンパイルはできるようになった（ワーニングが出てるのでNGっぽいけど暗号化の確認には問題ないだろうとスルーした）まあ万が一うまく暗号化の文字化けを修正できたら、バグ報告に追加できるし、Cygwinでビルドすれがワーニングが消せるだろうという目論見もある。

追記

海外の生産性が高いって嘘だろ。GhostScriptのBugzillaに上記バグを投稿したところ早速返信があったのだが、すごいコメントだった。こちらは暗号化したら文字が化けるといっているのだが、彼のコメントは「このコマンドに変更すると暗号化なしの結果が得られるよ」と暗号化しないコマンドを教えてくれたのだ。いやいや暗号化したいから暗号化してるんだよ？入力がPDFだと言っているのに暗号化しないPDFの取得方法を教えられてもさ、それ入力ファイルと同じでしょ。何なのほんとに

さらに追記

数時間後に不具合の修正と新しいバージョンがリリースされるまでの暫定対策を教えてもらえた。前回の不明コメントはいけずだったが、最初の投稿からコメントまでのスピード感と補足情報を追加してから3時間？くらいでの対策実施はまあまあの速度感だった。その間にこちらではGhostScriptのデバッグ環境の構築が完了したのだが、一歩及ばずという感じかな。ちなみに、暫定対策は　-dNEWPDF=false　というオプションを加えるというもの。実はこれは試したことがあったのだが、そのときは目次を付ける処理でのみ使っていてそのあと複数のPDFを結合して暗号化する処理ではつけていなかった。どうやら目次を付ける処理以降のすべての処理でこのオプションがついていないといけないらしい。非常に残念なことに実は2022年4月にリリースされた最新バージョンからNEWPDFがデフォルトになりそれ以前はNEWPDF=falseが標準だったらしい。どうりでWebで調べても同じ現象に当たらないわけだ。

これはバグではないのか？これまでの人生で何度も思ったが大体は自分の使い方が間違っていたのだが、今回は本当にGhostScriptのバグではないのかというものを発見してしまった。これがMicrosoft製品なら報奨金がもらえたかもしれないが残念ながらフリーで使わさせていただいているだけなのでしっかり確認してからバグ報告できたらと思う。

実際に何が起こっているのかというと、日本語で目次をつけるのは以前ブログで報告した内容なのだが、これで作成したPDFを暗号化すると一部の文字が化けるというもの。なんとなくバグが残っていてもおかしくなさそうなマイナーな使い方をしている自覚はあるが、暗号化がトリガーだと気づくのに一日要した。その原因としてはプログラムで目次つけと暗号化を一気に行ってしまっていたためだ。目次用テキストファイルの生成が悪いのかと文字コードを変えたりしながらいろいろ試してみたが変わらず、GhostScriptのコマンドラインで目次付けのみをやってみたら文字が化けていなかったことでようやく気付いた感じである。だって、暗号化と復号化で何で文字化けするの？もとに戻らない暗号化ってなによ。暗号化のオプションが間違っている可能性もあるのだが、オプションが違っても文字化けはダメだと思うのでバグ確定といっても差し支えないかもしれない。

ちなみに、化けるのは「名」→「吊」という特定の文字のみである。これはUTF16BEでMAC？の改行コードを含んでいる文字らしく、勝手に改行コードだと認識して変換されることで起こるらしい。

追記：ほぼバグ確定。LibreOfficeで作成した目次付きPDFをgswin64cのコマンドラインで暗号化しても化けた。自分のプログラムが一切介していないので間違いないでしょう。ちなみにLibreOfficeのPDFエクスポートで暗号化しても化けていなかった。てっきり内部的にgsを使用してるんじゃないかと思ったけど使っていないのね。バグレポートはしてみたがこちらが必要なのは今月中なのよ、、、

バグレポートへの対応が思った以上に早くてもう最新バージョンにはコミットされたらしい。コミットはされたがリリースはされていないので、リリース済の最新バージョンでの対応方法は-dNEWPDF=falseを付けることらしい。暗号化するときだけではなく、目次を付けて以降のすべての処理でつける必要があるようだ。なぜ、リリース済の最新バージョンなのかというとそれ以前のバージョンでは-dNEWPDF=falseがデフォルトだから。ということでバグレポート出してから半日強で完了。ありがたい。