してログ

このブログでは、主に技術系の話題やネット関連の話題を扱います。 ネーミングはまだしっくりいってないけど、「LANDHERE Web Site log」→「Site blog」→「Sitelog」→「してログ」、とりあえず。

自分用なので色々と中途半端な記事です。

データベースの作成
createdb DBNAME --encoding=UTF8 --lc-collate=ja_JP.UTF-8 --lc-ctype=ja_JP.UTF-8 --template=template0
日付のフォーマット
表現結果
桁揃えto_char(now(),'YYYY-MM-DD HH24:MI:SS')2019-04-21 09:31:22
前ゼロ抜きto_char(now(),'YYYY-FMMM-FMDD FMHH24:MI:SS')2019-4-6 9:32:02
ISO8601to_char(now(),'YYYY-MM-DD"T"HH24:MI:SS"Z"')2019-11-14T18:37:28Z
データベースのタイムゾーンを変更する
alter database DBNAME set timezone to 'Asia/Tokyo';
select pg_reload_conf();

ハンドルカバー初体験

愛車のハンドル表面が剥げてきたので、ハンドルカバーという商品を初めて購入してみました。ドレスアップアイテムという位置づけなので、ふだん車にお金をかけていない自分にとっては疎いカテゴリーになります。たくさん種類が出ているので正直どれがいいのか分かりませんでしたが、赤黒のツートンのものにしてみました。

取り付け

簡単に取り付けられると思っていたら、これがとんでもなく固くて大変でした。考えてみれば、ズレたりしたら責任問題にもなりそうなパーツなだけに、かなり固く締め付けるような作りになっているのでしょう。正直、サイズを間違えたか初期不良なのかと思うくらい固いです。

商品が壊れることを心配するくらい思い切りひっぱって、ようやく装着できたときは指の感覚が無くなるくらいヒーヒー言ってました。装着中に何度か手が滑って、クラクションを鳴らしてしまったのはおそらく「あるある」なのでしょう、場所を選ぶか十分気を付けましょう。あと、もう二度と外したくなくなると思うので、センターを出す必要のあるハンドルカバーの場合は慎重に位置合わせしましょう。

まとめ

今回ははじめてハンドルカバーを購入してみました。むかしスポーティ感を出すのに、ハンドルのセンター位置に白いビニールテープを巻く、というドレスアップをしていたのを思い出しました。このハンドルカバーも見違えるほど車内の雰囲気が良くなりますが、あのテープひとつで驚くほど効果があったのは内緒です。

購入は近所の量販店でもいいですが品揃えが少なかったです。ネットで検索すると、ハンドルカバーはかなり多くの種類が出ているみたいので、デザイン重視ならネット通販のほうがお勧めです。

評価点

  • 表面の禿げたハンドルの触り心地が良くなった
  • 車内の雰囲気がカッコよくなる(思ったより効果絶大)
  • 赤と黒のツートンはスポーティでおしゃれ(センターマークもレース感があって良い)

マイナス点

  • 装着のし難さ(安全性のため仕方ない面はあるが)
  • ハンドルが太くなる
  • 内側はカバーされないので、逆手ハンドルすると握り心地が悪い(矯正にはいい)
  • 片手でぐりぐり回すのがやり難い(矯正にはいい)
総合評価:★★★★☆

素直に買ってよかった。

PhD cat
PhD cat

PHP のマニュアルは DocBook という形式で整備されており、HTML や PDF などに変換して利用することができます。公式からダウンロードできる HTML 版が以前のようなシンプルなものでは無く、スタイルシートが適用された活用し難いものだったのでトライしてみたのですが、結論から言うと同じ構成のものが生成されるようです。そのため公式にない PDF を作りたい場合など、参考程度にどうぞ。

作業に必要なパッケージの確認

subversion と git が必要になりますので、入ってない場合は下記コマンドにてインストールしておきます。

yum install subversion
yum install git

XML ドキュメントを取得

マニュアルの日本語 XML ソースをリポジトリから取得します。

svn co https://svn.php.net/repository/phpdoc/modules/doc-ja doc-ja

続いてソース内の configure.php を実行しますが、-with-lang=ja を指定しないと英語版が出力されるのでご注意ください(処理時間も長いので)。

cd ~/php-docs/doc-ja
php doc-base/configure.php --with-lang=ja --enable-xml-details

関係ありませんが下記のような「AA」が出てきたのでご紹介します。

All good. Saving .manual.xml... done.
All you have to do now is run 'phd -d /root/php-docs/doc-ja/doc-base/.manual.xml'
If the script hangs here, you can abort with ^C.
         _ _..._ __
        \)`    (` /
         /      `\
        |  d  b   |
        =\  Y    =/--..-="````"-.
          '.=__.-'               `\
             o/                 /\ \
              |                 | \ \   / )
               \    .--""`\    <   \ '-' /
              //   |      ||    \   '---'
         jgs ((,,_/      ((,,___/

 (Run `nice php configure.php` next time!)

PhD(DocBook を PHP マニュアルに変換するツール)

以下のコマンドにて PhD をリポジトリから取得します。

cd ~/php-docs
git clone http://git.php.net/repository/phd.git

ここで生成処理が大量にメモリを消費するようなので、実行する前に PHP の使用メモリの上限を上げておきます。今回は memory_limit = 512M と設定してみました(php.ini を編集)。準備ができたら、xhtml 形式で randered-docs ディレクトリに生成します。

cd ~/php-docs/phd
php render.php --docbook ~/php-docs/doc-ja/doc-base/.manual.xml --package PHP --format xhtml --output ~/php-docs/rendered-docs

PDF 出力するには、--format pdf としますが、HaruDoc が必要になります。HaruDoc は今回はじめて聞いたのですが、使えそうな PDF 生成エンジンのようです。今回は試しませんが FPDF の代わりに今度使ってみようと思います。

マニュアル最新版のバグ

関数一覧ページがバグっていたので書いておきます。マルチバイト文字を ASCII として扱おうとしてバグっているように見えますが、ソース等確認していないのでわかりません。ちなみに、公式からダウンロードできる HTML もそうなっています。

indexes.functions.html
indexes.functions.html

移動に3日ぐらいかけて大量のファイルを移動させたら、残りゼロのまま1時間以上処理が終わりませんでした(何してるのか不明だが待てば終わる)。少ない量でもゼロになってから少し待たされると思いますが、ファイルの転送量に比例してこの後処理の時間は長くなるように思います。

それにしても「残り5秒」とかトラブってるのかそうで無いのか判断に困る、こういう表示が不安になるんですよマイクロソフトさん。あと転送速度も 1.37GB/s とかあり得ない表示になってるし、転送中も「残り2日以上」「残り17時間」などと行ったり来たり、当てにならない表示はするくせに「今どのディレクトリを作業しているのか」といった必要な情報は表示してくれないんですよね。

あと、処理開始前にファイル数カウントアップするの止めてもらえませんかね。数十万~百万ファイルもあると、それだけで1時間とか平気で待たされてしまいます、Windows 最悪です。

2台あるうち1台の ReadyNAS 104 で転送速度が 10MB/s と遅い問題に悩まされていましたが、原因が暗号化ボリュームにしていたためと分かりました。この機種は、ソフトウェアで暗号化するようですので、ハードウェアで行う機種に比べてかなり転送速度が落ちてしまうようです。しかし、暗号化によって速度低下するのは理解できますが、このように著しく低下するならもっと周知して欲しいと思います。

解消するためにボリュームの再構築で、全データをどこかに退避しなければなりませんが、8TB ぐらいあるので置き場所に困っています。所有している PC と外付けに分散すればなんとか退避できそうな算段はあるのですが、問題になっている転送速度が 10MB/s だと何日掛かるやら...。これから NAS を導入する際には、設定に十分な検討が必要だと思いました。

しかし、10MB/s 以下の転送速度では誰かが大きなファイルを転送するだけで、他の接続はほとんど出来なくなります。実質ファイルサーバーとしては利用できなくなる訳で、あっても使えない機能なら宣伝するのやめて欲しいと思います。ネット上のレビューなども暗号化できますとは紹介していても、転送速度の低下については触れられていない無責任な内容が多いです。

暗号化解除するのに今、全ファイル(8TB くらいある)を所有 PC や外付け HDD に分散して退避しているところです。この退避で常にファイル転送していますが、この状態だとファイルサーバーとしての利用は難しいです。退避だけで何日も掛かるのに、その間ファイルサーバーが使えないのは非常に辛いですが、やるしかないですね。

先月か今月(2019年9月)のマンスリーアップデートは他の不具合でロールバックして適用していないのだけども、問題が無かった環境でもタスクスケジューラで不具合を発見して、もう最悪なんですけど...。ひとつは実行ユーザーの設定の問題、もうひとつは subst と組み合わせた際の問題、いずれも対処可能です。

実行ユーザの設定でコンピュータ名を必ず聞かれる

ログインしていなくても実行される設定では実行ユーザを設定すると思いますが、このようなタスクはユーザを変更しなくても、もう一度入力しないと適用できません。恐らく「コンピュータ名¥ユーザ名」と復元すべきところを「ユーザ名」としたバグではないかと思います。前の状態がどうだったかは知りませんが、少なくともユーザ名を変更しないときは再入力を求められることは無かったと思います。

subst で仮想ドライブ化したディレクトリにアクセスできない

subst コマンドで仮想ドライブ化したドライブに置いたプログラムを実行できなくなりました。「ディレクトリが見つかりません」となります。

そもそも Windows10 ではコマンド実行による subst はできなくなりました。しかし「Windows 10で「subst」コマンドは使えない? 」の記事にあるようにレジストリを設定して回避可能です。この記事では、2つの方法が紹介されていますが、1番目の方法ではタスクスケジューラで前述のエラーになります。今のところ、2番目の方法ではタスクスケジューラでの動作も問題ありません。

また VMware のサイトで迷ってしまったので最短ルートをメモっておきます。各ページにリンクを貼っておくので、一番下から試していくと最短も最短になると思いますよ。

  • my vmware にログイン
  • 製品およびダウンロードをクリック(右上にあるアイコン) ⇒ 製品ダウンロード
  • パッチのダウンロード(右側にあるリンク) ⇒ 製品パッチ
  • 製品種別から ESXi (Embedded Installable) を選択
  • バージョンから 6.7 を選択して検索

ちなみに、現時点で最新版である VMware vSphere Hypervisor (ESXi) 6.7 update 3 の ISO のダウンロード先はこちら。

Windows7 をクリーンインストールして、Windows Update で最新版にアップデートしようとしたところ、エラーコード 80092004 で失敗してしまいました。マンスリーアップデートを適当に遡って2019年3月で失敗、2019年2月で成功となったので、ここから順に適用して9月まで持って行こうとしました。しかし、2019年8月でまた失敗、でその KB 番号「KB4512506 80092004」でググってみてようやく原因が判明しました。

こちらの記事にある「更新パッケージの署名を SHA-2 でのみするよう変更された」のとおり、更新パッケージの暗号を解釈できないためエラーになっているようです。この解決には、KB4490628 を前もってインストールしておくことで回避できるとのことです。

役に立つかも知れないメモ

  • マンスリーアップデートを見つけるには「Windows7 マンスリーアップデート2019年5月」などで検索する
  • アップデートの KB 番号が分かったら「KB4490628 catalog」などで検索すると簡単に見つかる

先月の Windows Update では、仮想マシンにリモートデスクトップ出来なくなり、今月のは NAS とのファイル転送がおかしい。NAS のファイルを移動しようとしたら途中でフリーズし、キャンセルも何も効かなくなった。explorer を強制終了させ、[新しいタスクの実行]から再起動してみたが、ファイルの操作が異常に重たい。フォルダも数分待たないと開かない。PC 自体を再起動させ、もう一度ファイル移動させるが、すぐにまた重くなる。フォルダの表示、ファイルのリネーム、その他すべての動作が重い、重い、重い!!

この記事書き始める前にリネームしたのに、今もまだ処理が終了してない。タスクマネージャーで見ると、エクスプローラーが2つ「応答なし」になっている。今ようやくリネーム処理が終わったが、もう1個のフォルダ表示は緑のプログレスバーが止まってる(10個くらいしかファイル無いのに!)。間違いない。Windows10 は史上最悪の糞OS だ。

書き終えてアップデートを元に戻そうと再起動したら、いつまで経っても終わらない。強制リセットしようにも、ハードディスクにずっとアクセスあるし、なんなんこれ。もう5分以上掛かってるので、ノーパソで続き書いてるけど、まだ終わらんな。ハードディスクのアクセス断続的になってきたんで、強制リセット掛けて自動修復モードへ移行。なんかもう、やり慣れて自動修復職人になってきた。

ちなみに自動修復は、手動でメニューを選んで進めなければならんので自動なんかじゃない。しかも非常に時間が掛かるので、まーやりたくない。修復が終わっても、起動が遅くデスクトップまで行ってもデバイスの接続音やらなんやらで、要するに Windows Update 後の起動と同じ。こうやって Windows10 は我々から時間を奪っていく。

最新の品質更新プログラムのアンインストール後に元に戻ったのを確認し、即行で Windows Update を停止しました。これで1ヵ月は大丈夫なはずですが、8月末みたいな緊急アップデートみたいなのがあると、勝手にやるみたいなんだよな。同じように1ヵ月停止にしたはずの環境が、勝手に再起動掛かってて不具合再発みたいなのあった気がする。とにかく最近の Windows Update の品質は最悪だと言わざるを得ない。