KiCAD 5.1.4日本語フォント対応

新しい版が登場しました。マイナーチェンジなので気にするなという意見も有りますが、やはり新しい奴には気を惹かれます。

例によってFedora版はFontファイルを入替えてrebuild成功。で、次はWindows版だというわけで作業。5.1.0の時の話を参考にしたのですが、謎の状態になったので一旦全部削除してやり直し。

とりあえず素の状態だとどうなるのかが気になったので、あえて何の変更も加えずに作業開始。Fedoraのrebuildに比べると大分に時間がかかりましたが、どうにか終了しています。

早速起動してみましたが、あれこれのdllが無いぞと苦情が… Logを見ると結構な数のdllが不足の模様。なので無変更で作成できるほど甘くはないことが判明した次第。
作業時間が不足したので、ここまでで中断中。

それにしても驚いたのが必要となるディスクスペース。ほぼLinux環境を新たに作成する雰囲気で、全体で40GBほども消費してくれます。細かいファイルが多くディレクトリも多数、しかも深く掘られているので消すだけでもかなりの時間を要します。もうちょっと簡潔に出来ないものかと思うんですが… これだからVS上でなんとかしようともがく人たちが出てくるわけです。
今の所成功した人は居ないようですが…

LAMP on Fedora30

仮想PCでのCentOSはとりあえず一段落。で、もともとFedora上で動かしてみたらどうなるのかということで環境構築。

いろいろとパーミッションの関係で引っかかたので対策をメモしておく。

cgiの起動許可はSelinuxをDisableにしてさらに、/var/run/httpdのオーナーを変更してクリア。
php系のcgi-handlerの起動失敗の方は/etc/php-fpm.d/www.confのユーザーとオーナー部を書き換え。これだけでは駄目だったので、/var/run/php-fpmのユーザーとオーナーを書き換えてクリア。
さらに/var/lib/phpのopcache/とsession/とwsdlcahce/のユーザーを書き換え。

しかし、CentOSを設定した時にこんな面倒は無かったのに不思議だ。こんなことなら、素直にユーザーapacheを作成しておいた方が早かったかな。

仮想PCその2

VirtualBoxのインストールは無事終了です。こちらもカーネルバージョンに依存するモジュールがあるのですが、第三者のパッチを当てて処理なんてことはないので、今後のカーネルアップデートでも多少楽できるかな。

問題は、画面の広さと違和感の残るマウスやキーボード入力。今時SVGA(1024×768)しか広げられないのってどうなんでしょう。マウスにしても仮想PC内外の識別がいまいちでなんかちょっと…

まぁ、HOST環境がLinuxなのだから、こちらでLAMP app(Apache,MariaDB,PHP)を動くようにするのが一番手っ取り早いのはわかってますけど、それだと進歩がない気がしてね。

XenとKVMにも挑戦してみますか。

仮想PC

職場サーバーの環境整備として、自分のPCに仮想マシンをインストールして、そこであれこれ作業しています。いきなり本番機でやるとトラブルの時の始末が大変だからで、まぁ当たり前と言えば当たり前のことではあります。

で、自宅のLinux(Fedora)上でも仮想PCが動くのかと思い作業。いろいろとトラブルはあったのですが、VMware Playerは無事に起動。職場の仮想PCもそのまま持っていくこともできて一安心。のつもりでしたが、2日後にKernelアップデートが有ってあっさりと動かなくなりました。

もともとカーネル系でトラブルが起きるので専用のパッチがあったのですが、そいつが最新カーネルには対応しきれず、対応モジュールが作成できません。

いろいろ見てみると、Fedoraに限らず、Ubuntuでもカーネルのアップデートで動かくなったという相談が多数。これだと頻繁にカーネルが更新されるFedoraのような環境では安心して使用できないのでVMwareは使用断念しました。

となると次の仮想PCですが、Linux界隈ではXenが有名ですが、私のやりたい方向とは違っている雰囲気。なので次善の策としてOrcaleのVirtual BOXを選択。ホストOSのカーネルに敏感でなければいいなと思う次第。

とりあえず、なぜかVMwareに付属しているツールでVMware上の仮想PCをOrcaleでも読み込める形に変換してトライ開始。
さてはてどうなるかな。

太陽電池その2

ようやく太陽が拝めた休日にテストです。とは言え付きっ切りで世話していたわけではないので、もしかすると半分ぐらいしか効率の良い時間帯は無かったかもしれません。

11:00～16:00までの5時間で途中2回ほど位置調整をしてやって10000mAhのモバイルバッテリーのレベルインジケーターが1から3になりました。ちゃんと充電されたのでムダ金にならず一安心ですが、予想よりちょっと効率が良くないな。

やっぱり基本的にテントに張っておくとか、リュックの背中に広げておくといったアウトドア方面の使用方法が正しいのだろうか..
まぁこいつが活躍するときってのは、周りに電気が無くて、しかも時間は余っているという状況のはずなのでこんな物でもいいのかもね。

太陽電池

近頃ではSolarCellという言い方が流行ってますが、ヲジサン的には太陽電池の方がしっくりきます。

SolarCell
充電用太陽電池

さて最近変なところが震源の地震が多いので、用心のために購入です。価格は某尼損で約5500円。ちなみにAnkerは販売代理店としてここを使用しているので、このモデルはここでしか手に入らなかったりします。私個人的には税金をちゃんと納めない不届きな組織の利益の足しになるようなことはしたくないのですが、仕方がありません。

しばらく天気が悪かったせいで、試せずにいましたが、ようやく晴れたのでテスト。室内というか、周りに建物がある環境だと太陽を追っかけるのが大変。
曇りでも昼間程度の明るさが有れば、発電中インジケーターは点灯しますが、さらに充電用に供給するほどの余裕はない模様。実際には写真のように直射日光に曝さないとまともには発電してくれません。

カタログでは最大5V 3A(15W、ただし1ポートあたり2Aまで)の出力となっていますから、私のスマートフォンのバッテリー(3Ah)は1.5時間で満充電できる勘定となりますが、本当か?　モバイルバッテリーは容量が10Ahなんで5時間かかるって、ほぼ一日ってことだよな。
実際問題として直射日光に曝すと温度が気になるんだけど大丈夫なんだろうか。まさかエアコンの効いた室内の日当たりの良い場所で使用じゃないだろうな…
一応アウトドア用ってなっているので大丈夫なんだろうけど。

選挙

国政選挙をやっています。与党からのお達し(H氏の呪い!?)のせいで、TVやラジオでは盛り上げられない変な状況になってます。その割に変なCMが流れてきて非常に鬱陶しかったりしますけど。

ところで現在の住居地と勤務地は隣接しているのですが、今選挙ではとうとう1度も選挙カーに遭遇すること無く運動期間が終了しました。駅に行けば立会演説会くらいはやっていたのかもしれませんが、なかなか珍しいことです。
まぁ両方合わせても人口が10万前後、ということは投票権をもって居る総数がせいぜい6万ってところですから、大勢に影響無しって分析なのかな。なんか舐められてる気がするけど、現実なのでしょうがないですね。
それに「ド田舎」ってやつなので、自公が圧倒的に強いっていうのも選挙カーが来ない原因の一部なんでょうね。まぁ、静かで本当に良かったですが。

さて、結果はどうなるのでしょう。結果次第では、後の世に「最後のまともな選挙」と呼ばれる状態が出現しないとも限りませんがみんなそれに気がついているのかな。

MDB2 to PDOその3

5つのシステムのうち4つまでは完了。PDO対応を進めつつ、以前は理解力不足で機能させられなかったJavascriptによる事前チェック機能などを整備してだいぶ使いい勝手も良くなりました。

最後の一つは一番新しい奴なんだけど、変な色気を出してフレーム構造にした結果、処理制御が難解になっています。
何周遅れてんだよと嘲笑が聞こえてきそうですが、PHPのsession管理を利用すれば、今はformのPOST機能で利用している長いパラメーター文字列の何文字目が□だったらこの処理、△だったらこっちの処理なんて複雑な事をする必要がなくなることが判明。
この機構を利用してやる予定だけど、中身が大幅に変わるので、少し時間がかかりそうだな。

Javascriptを利用した場合、手っ取り早くブラウザのWeb開発モードを利用してデバッグするのだけど、反応が悪くてとてもしんどい。画面が狭いもの悩みの種。専従じゃないので、わざわざ別ディスプレイを用意してっても大げさだし、なにより現在VM Player上のCentOSで作業しているので、VM環境のLinuxがマルチディスプレイに対応するかどうかも怪しいしね。

MDB2 to PDOその2

仕事の合間に片手間でやっていたMDB2からPDOへの移行。第一弾がようやく完了です。

やり方によって、処理結果がObjectだったり単純変数だったりといろいろなので、面食らいながらもなんとか書き換え終了です。
PDOの目玉であるpreparedステートメントを利用すると、DBに届く実際のクエリが確認できず、一点だけ問題が解決できないままとなってしまいました。この実際に投げているクエリが確認できると、とても良いんだけどな。

今回改良した処理システムは2006年からチマチマとイジりながら運用していたもので、現時点でソースを読み返すと、SQL文を工夫すればクエリの結果からデーターを選別しなくても良いのにという点が多々有りました。その辺は改良したので、少しは全体的に早くなったかな。

それと、HTML部とphpソースが混じっいて読みにくいですね。システム的にはOKになっているけど、もう少し改良しなくては。それと残り5つの処理システムがMDB2のままなので、こちらも書き換えていかなくてはいけないな。

乱数の質その2

モンテカルロ法だとよくわからなかったglibcとMelsenne Twisterの違い。ならば単純にヒストグラムを取ったらどうなるという訳でテストです。
一様乱数だと処理が面倒なので、0から9999までの乱数を発生させて、各数値の発生回数をカウントします。

全体で1010回の試行の結果は次の通り。

分散の値はMTの方が大きくなっているけど、そういうものなのかな??

実際的にはホワイトノイズ(例のシャーってノイズ)にA/Dコンを接続したものや量子力学的現象を利用するとかいろいろな方法が提案されていますが、何が一番なんだろうな。というか、乱数の質ってなんだか哲学的な話になってきたので簡単には結論は出せないんでしょうけど。