pipでアップデートを半自動的に行う方法。

結論から先に書きますが、全然半自動にすらなっていません。試してみたことのメモです。

Python 2/3でいくつかのモジュールをPyPiからインストールして使用していますが、モジュールがアップデートされたときにはキャッチアップしたいときがあります。ところが現状 pip ではアップデートがあるモジュールを自動で検索して全部を一括してアップデートできません。

pipに一括アップデートがない理由のひとつは、モジュールの依存関係にあるようです。

あるモジュールAが、たとえばモジュールBのバージョン 1.0 に依存しているとします。モジュールAはバージョンアップしていませんが、モジュールBが2.0にバージョンアップしました。ところがモジュールBのAPIが変わってしまい、モジュールAはモジュールB 2.0では動作できなくなりました。

というようなことが現実に起こり得るため、盲目的な一括アップデートは推奨されていません。

また、検索してみるといくつかヒットして、いずれも "pip list" で一覧を取得して、総当たり的にすべてのモジュールに "pip install -U" をしかけるという形のようです。同様のことが、Unix系の環境では pipdate というユーティリティで行えます。これは pipdate / pipdate3 というスクリプトと、pipdateモジュールを提供していますが、スクリプトの方は以下のようになっていました。

pipdate3:

pip3 freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip3 install -U

同様に依存関係には無頓着にアップデートしてしまうようです。

依存関係をチェックするためには、pipdeptree があります。

自分の環境で pipdeptree を使ってみたらコンフリクトの警告が出ました。

$ pipdeptree
Warning!!! Possibly conflicting dependencies found:
* neovim-remote==2.0.10
 - neovim [required: >=0.2.3, installed: ?]

これは、neovim-remote が neovim-python に依存しているのに、neovim-pythonからpynvimへ。で触れたように neovim-python が廃止されたから、でしょう。

ということで neovim-remote をアップデートします。

$ pip install -U neovim-remote
Collecting neovim-remote
  Downloading https://files.pythonhosted.org/packages/23/55/89b7528c43771e63b0b035b78dd8a05de29cc8c7a9bcf1b1b155df095a6f/neovim-remote-2.1.3.tar.gz
Requirement already satisfied, skipping upgrade: pynvim in c:\apps\python37\lib\site-packages (from neovim-remote) (0.3.1)
Requirement already satisfied, skipping upgrade: psutil in c:\apps\python37\lib\site-packages (from neovim-remote) (5.4.6)
Requirement already satisfied, skipping upgrade: setuptools in c:\apps\python37\lib\site-packages (from neovim-remote) (39.0.1)
Requirement already satisfied, skipping upgrade: msgpack>=0.5.0 in c:\apps\python37\lib\site-packages (from pynvim->neovim-remote) (0.5.6)
Requirement already satisfied, skipping upgrade: greenlet in c:\apps\python37\lib\site-packages (from pynvim->neovim-remote) (0.4.13)
Installing collected packages: neovim-remote
  Found existing installation: neovim-remote 2.0.10
    Uninstalling neovim-remote-2.0.10:
      Successfully uninstalled neovim-remote-2.0.10
  Running setup.py install for neovim-remote ... done
Successfully installed neovim-remote-2.1.3

$ pipdeptree --packages neovim-remote
neovim-remote==2.1.3
  - psutil [required: Any, installed: 5.4.6]
  - pynvim [required: Any, installed: 0.3.1]
    - greenlet [required: Any, installed: 0.4.13]
    - msgpack [required: >=0.5.0, installed: 0.5.6]
  - setuptools [required: Any, installed: 39.0.1]

これで警告が消えました。

今回は簡単でしたが、一括アップデートしたい場合には、pipdeptreeで「バージョンがxx以下であること」という依存関係があるかどうかをチェックしてから行うほうが安全のようです。そういう目で見てみると、

flake8==3.5.0
  - mccabe [required: >=0.6.0,<0.7.0, installed: 0.6.1]
  - pycodestyle [required: >=2.0.0,<2.4.0, installed: 2.3.1]
  - pyflakes [required: >=1.5.0,<1.7.0, installed: 1.6.0]
requests==2.21.0
  - certifi [required: >=2017.4.17, installed: 2018.11.29]
  - chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
  - idna [required: >=2.5,<2.9, installed: 2.8]
  - urllib3 [required: >=1.21.1,<1.25, installed: 1.24.1]

あたりは引っかかりそうです。 あとついでに、pip自身のバージョンが古いんですけどー、といわれた場合には、Windowsの場合は

python -m pip install -U pip

を、Linuxの場合は

pip install -U pip

すればいいです。
"-U" は "--upgrade" と同じ意味です。

Contact Form 7にreCapcha v3を導入する。

WordPressでサイトを運用していて、「お問い合わせページ」などを Contact Form 7で作成し、さらにスパム避けに reCAPCHA を使っているのですが、Contact Form 7がバージョンアップして reCAPCHA v3 への対応になりました。それに伴って、これまで [recapcha] と指定していた Contact Form 7 の問い合わせフォームのキーワードが無視されるようになりました。

reCAPCHA v3 のページには、Fronend integrationとして設定例が載っていますが、Contact Form 7はreCAPCHA v3に対応しているのでこれは不要になります。正確には Contact Form 7 の「インテグレーション」メニューから reCAPCHA v3 をインストールすることで、自動的に Contact Form 7 が reCAPCHA v3 を利用するようになります。また、これまで使っていた問い合わせフォームの [recapcha] は単純に削除されます。

reCAPCHA v3はこれまでのような「ユーザにロボットでないことを入力させる」という動作がなくなります。同時に、これまで使っていた v2 の登録キーが使えなくなり、新たに v3キーを取得する必要があります。

登録方法は他に譲るとして、v3はどういう動作になるのかをドキュメントから簡単にまとめてみます。

reCAPCHA v3 は、これまで主流だった CAPCHA によるユーザ確認（難読化した文字を読み解いて入力させるとか、チェックボックスをチェックさせるとか）を廃止し、ユーザの "アクション" をもとにしてスコアを生成して送信します。より精度の高いスコアを生成するためには、サイトの複数のページに reCAPCHA v3 を埋め込んで動作させることが推奨されます。それによってユーザの動作を追跡し、SPAMボットかどうかを判定することが容易になります。reCAPCHA v3の動作の様子は、reCAPCHA管理コンソールで確認できます。

安全グラス。

PCでの作業や、細かい作業をするときにはメガネが必要なのですが、電動工具を使うときにも眼球へのダメージを防ぐために安全グラス、安全ゴーグルは必須です。

この時期ですとスポーツ用品店で、防曇（ぼうどん）仕様のスキーゴーグルなんかがよいかもしれませんが、オールシーズン通じてとなるとスキー用は夏場がちょっと…。それにバンドの部分が汗で大変なことになったりもしますし、水洗いも気軽にできるという点ではグラス型のほうが好みです。ただ、横までカバーしないものは粉塵に対しては防御力が薄いですし、グラス型でもサイドまで防護してくれるものが理想です。

自分ではメガネ対応の安全ゴーグルとして "Crews Yukon XL Z87+ Safety Glasses" というのを使っています。透明性も高く、メガネ越しでも歪みがほとんどないので結構気に入っていますが、これが防曇（antifog / defog）ではないので曇りやすいのと、ちょっと小傷がついてきたので磨けないかということで調べてみました。

素材はポリカ、ANSI Z87+の耐衝撃性とCSA Z94.3に適合しているということらしいです。'+'というのは余裕でクリアしているというアピールでしょうか。認証をとっているかどうかはよくわかりません。

ミドリ安全の保護メガネには、海外規格との比較というページがあります。ここでANSI Z87.1規格について出ていますが、屈折率とか非点収差度、耐衝撃性などがわかります。さすが、ミリタリー規格だけあってZ87は数値が厳しいです。

ミドリ安全では防曇・メガネ併用型でANSI規格も対応しているVS-302Fというものがあるようですね。ツルはナイロンでボディはポリカとのことです。
また、スキーゴーグルではスワンブランドの山本光学ではオーバーグラス SN-770というのもあるようです。こちらはANSIについては書かれていません。

さて、こうした安全グラスも工具箱などに放り込んでしまうとあっという間に傷だらけです。そうすると視界が悪くなってきますし、光が散乱して見づらくなってくるというのもありますので、できるだけ傷はつけたくないものです。それでもついてしまった傷は、材質がポリカですから、自動車のヘッドライト研磨と同様に処理できるはずです。

具体的には、ちょっと深めの傷があれば400番程度から、ちょっとした擦り傷程度なら1000番程度からの耐水ペーパーで水研ぎし、2000番、3000番、4000番あたりまで使って（3000番以降はお好みで）研磨してから、研磨剤で磨いてやるといいようです。

ペーパーだと指先の部分だけ強くあたってしまうため、スポンジ研磨材というものも有効なようです。3Mから、5083（#320～#600）、5084（#800～#1000）、5085（#1200～#1500）という感じで出ています。ただ結構お高いので、これなら安全グラスを買い替えてしまったほうが安そうです。

いずれにしても、自分にあった安全グラス・安全ゴーグルを一つは用意しておきたいものです。

Windows10の新しいSandbox。

Windows Sandbox is a new lightweight desktop environment tailored for safely running applications in isolation.

Windows10にSandbox機能が追加されるというお話。

Sandboxというのは本来のシステムとは隔離された環境のことで、たとえば疑わしいアプリケーションをSandboxで動かせば、万が一ということがあっても本来のシステムは影響を受けなくなります。

たとえばPythonであればvirtualenvがそれに当たります。

WindowsでSandboxを使いたい場合、今まではVirtualBoxなどの仮想環境を持ってきて、そこにWindows仮想PC環境を構築する方法が取られていました。このとき、その仮想マシンのスナップショットを保存しておけば、何かをインストールして問題が起こった場合でもロールバックできます。

Windows Sandboxは仮想マシンを使わなくてもSandboxを利用できる、というのが上記のリンクの内容です。

ただし利用するには条件があって、Windows 10 Pro または Enterpriseエディションであることが必要とのこと。さらにこの機能は今のところInsider build 18305以降でしか利用できないようです。またメモリを4GB（できれば8GB以上）、CPUコアを2つ以上（できれば4つ）あることが望ましいようです。

うちではProエディションですが、バージョンは1803でInsiderではありませんからまだ当面は使えそうにありません。

また仮想マシンとは異なり、あるアプリケーションをインストールした状態で停止することができません。Sandboxは毎回完全にクリーンな状態で起動するということで、たとえば日本語Windows10上で英語Windows10の開発環境を構築するというような目的の場合にはこれまで通り仮想マシンを使う必要があります。

Notepad++にPlugin Managerをインストールする。

エディタはPCを使うときになくてはならないものですが、うちでは秀丸、gVim、Notepad++、Neovim、Visual Studio Codeの5種類を目的に応じて使い分けています。さらにファイルの差分をみたいときにはWinMergeを使っています。
また、PICのプログラミングをするときにはMPLAB IDEを、C#やPythonを使うときにはVisual Studio 2017を使うときもあります。

ところで最近のNotepad++にはPlugin Managerがついていません。これは作者の方針で、Plugin ManagerがAdwareであり、広告を表示するのでバンドルしないことにした、ということです。同時に「広告を表示しない新しいPlugin Managerを開発中だ」ともありました。

反面、広告入りであれ従来のPlugin Managerは大変使いやすかったためにファンも多く、コミュニティでは再バンドルを求める声もずっと続いていて、ユーザが自分の判断で追加でインストールすることは可能です。

githubのbruderstein/nppPluginManagerにはコンパイル済みバイナリがリリースされているので、ここから適切なバージョンをダウンロードし、%ProgramFiles%\Notepad++ディレクトリ以下にコピーするだけで使用できるようになります。64bit版のNotepad++の場合にはx64を、それ以外はUNIを選択すればOKです。

一方、Notepad++ v.7.6からは新しいPlugins Adminが同梱されるようになりました。

Notepad++ v.7.5.xからv.7.6.xへは、これまでのupdaterではアップデートできないため、ユーザが明示的にv.7.6.xをダウンロードしてインストールする必要があります。現在のバージョンはv.7.6.1で64bit環境の場合には下の方にx64インストーラがあるのでこれを使います。もちろん32bit版でもまずいことはありませんが。

見て分かる通り、Plugins Adminにチェックが入っています。

インストール後に起動すると、プラグインメニューに「プラグイン管理」の項目があります。

見た目もこれまでのPlugin Managerに似ているため、違和感なく使えるでしょう。

ということでv7.5.xを使っている人はv.7.6.xにアップグレードを推奨です。

18%グレーの作り方。

写真ってなんでしょうか。

映像を記録するもの、なんですが、そこには2つのアプローチがあると思っています。1つは写実という観点。これは現実をできるだけそのまま写し取ることが目的です。カラー、白黒、セピアなど色彩にはいろいろありますが、いわゆる撮って出し。撮ったあともトリミングや露出補正などはしますが、基本的には被写体に忠実であることが求められます。もう一つが表現という観点。いわゆるアート、芸術です。たとえば夕焼けのオレンジを強調したり、モノクロ写真の一部だけをカラーにしてみたり、フィルターなどを使って加工してみたり。

フィルムカメラをやっていた頃は多彩な表現というのは難しく、フィルム、ライティング、現像方法、焼付、レンズフィルタなどで表現を創出していました。

一方、デジタルカメラでは受光素子は固定のため、一部のレンズフィルタなどを除いて後処理ですべてを決定していきます。そのときに基準となるのがカラーチェッカーです。

カラーチェッカーは色味の確認のためにスタジオなどでの撮影には必須です。照明などの条件を一緒にして撮影しておけば、のちの確認の際に使えます。もちろんフィルムカメラでも使用しますし、最終的な印刷の際にも色合わせで使用します。スタンダードなのはx-riteのColorChecker Classicです。

また、色見本的なカラーチェッカーとは別に、露出やホワイトバランスを決定するのに18%グレーというのがよく使われます。

これはx-riteのColorChecker Gray Scaleですが、中央のグレーが18%です。

WEB上には "18% gray card" で検索するとPDFなども見つけることができますが、ここでは自分のところで作ってみます。

いつも使っている Krita では印刷機能がないのと、どうもLab色空間の扱いに難がありそうなので GIMP2を使います。

1. 「ファイル」→「新しい画像」で新規ファイルを作成します。サイズは自分の欲しいサイズにします。印刷して使う場合には、プリンタのdpiを調べて「詳細設定」で指定しておきます。
   
   
2. 色の設定をします。HSVを選択し、Vを50にします。
   
   
3. 塗りつぶしツールを選択して、ファイルを塗りつぶします。
   
   

これで希望のサイズのグレーカードができました。あとは真っ白い厚紙か、印刷可能なプラ板などに印刷すれば使えます。

自分の場合、ノートPCの液晶画面にどうも色むらがありそうなので背景として表示してチェックするのに使用しました。特におかしなところはなくてやれやれです。

UVレジン価格比較表。

UV硬化型レジン。ではパジコの製品を比べましたが、ここでは清原のものとの価格を比較します。（）内はアマゾンの価格を引いてきています。

メーカー	パジコ	清原
品名	太陽の雫	UVR500G
価格(25g)	1200円(1136)	1500円(857)
gあたり単価	48(45.44)	60(34.28)
価格(55g)		2900円(1663)
gあたり単価		52.73(30.24)
価格(100g)	3800円(2917)
gあたり単価	38(29.2)
価格(200g)	6800円(4205)
gあたり単価	34(21.03)
価格(500g)	15500円(10280)	19800円(13764)
gあたり単価	31(20.56)	39.6(27.53)

g単価だと、パジコの200g、500gがかなり安いですね。ただ、価格でいうなら2液のレジンのほうが安いです。

資材や工具の通販。

会社での仕事やDIY的な作業に使う資材や工具は、ドイト、カインズホーム、ジョイフル本田などの実店舗に行って現物を確認してから購入したり、Amazonやヨドバシドットコム（そういえば最近ドットコムってあまり聞かなくなった気が）、モノタロウや楽天などを使い分けたりしています。

最近価格.comで安値の方に出てくるのがDCMオンラインで、しかも自サイトだけじゃなくて楽天にもYahoo!にも出店してたりしてすごいですね。たしかに新しく通販アカウントを作るよりは、楽天会員なら楽天に出店してればそちらで買うでしょうし商売がうまい感じです。

実はアルミパイプを切断する必要があって、9.0φx0.5mmという薄いアルミパイプなのでチップソーや切断砥石を使うほどではないため、パイプカッターで切ることにしました。ちょっと個数が多いので大変ですが、このくらいのサイズだとパイプカッターを固定してパイプを回せば簡単に切れます。

当然ながらパイプカッターは押し切る構造なので、切り口は内側にバリが出ます。そのバリをきれいに削りたいので、先日購入したIXO5というコードレスドライバに使える六角軸の面取りカッターを探していたのでした。

9.0φx0.5mmということは内径は8.0φなので、実はスチールデスクの引き出し修理に使用したステップドリルの8mmの部分でもできるのですが、面取りカッターがひとつあれば皿木ねじなどの皿もみにも使えるのでちょっと調べていて、DCMオンラインというのが気になったので調べてみました。

DCMオンラインはDCMホールディングスが経営しているネットショップで、ダイキ（愛媛）とカーマ（東海・北陸）、ホーマック（北海道・東北・関東）が経営統合し、そこに三井物産が物流として絡んでいるけっこう大きい会社です。さらに2017年にはケーヨー（ケーヨーデイツー、関東甲信越・東海・近畿）とも資本・業務提携していて、ホームセンターとしてはかなり大きい感じです。

今回欲しかったのは新潟精機のRM-12という六角軸タイプの面取りカッターで、これがAmazonだと1,080円、ヨドバシだと850円、DCMオンラインだと670円と、かなり値段に開きがあって気になります。

店の名前というともうひとつ気になっているのが藤原産業。SK11というブランドはよく見ますが、最近E-Valueというブランドも出しているようです。が、その棲み分けが今ひとつわかりません。まったく同じものをブランドだけ変えて出しているケースもあるようです。最初E-Valueは中国の怪しげなブランドだと思ってしまいましたが…。
藤原産業のサイトには、SK11はスタンダードブランド、E-Valueはベーシックブランドとの説明がありますが、どう違うのやらさっぱりです。

パイプカッターの替刃。

以前に自転車のハンドルバーの長さを切り詰めるためにパイプカッターを購入しました。
今回、別件でまたパイプカッターを使うことになりそうなので工具箱から出してきました。

手元にあるのは新潟精機（SK）のパイプカッター PC-Mです。Mサイズということで、アームの内側に適用パイプ径が刻んであり、4-28mmとなっています。新潟精機には一回り大きいPC-Lというパイプカッターもあり、こちらは6-42mmです。

パイプカッターは、パイプを加えこませてパイプの周りをぐるぐる回しながらネジを回してカッター刃を切り込ませていきます。壁際のパイプなどのように回すスペースがない場合にはラチェットパイプカッターという、ラチェット機構がついたものがあります。

ところでパイプカッターの刃は丸刃なのですが、新潟精機からは替刃として2種類でています。PCB-1とPCB-2です。それぞれ2枚組で売っていますが、値段はPCB-1のほうがPCB-2の倍くらい高いです。

何が違うのか、Amazonなどの通販サイトでは表示されていないので調べてみると、新潟精機のDIYカタログに説明がありました。

いわく、「ステンレスには別売品ステンレス用替刃 PCB-1をお求めください」だそうです。その他アルミや鉄パイプなどはPCB-2でよいようです。

L-SMASHとL-SMASH Works。

aviutlで動画を読み込むときにL-SMASH Worksを使っていますが、ちょっと調べたので自分用メモ。

まずL-SMASHから。

L-SMASHはISO Base Mediaファイルフォーマット及びMP4を含むその派生ファイルフォーマットを扱うクロスプラットフォームのライブラリです。

これだけだと抽象的すぎてよくわかりませんが、その下に機能説明があります。

• β版レベルのMultiplexer(マルチプレクサ)及びDemultiplexer(デマルチプレクサ)として動作します。
• スタンドアローンな実行ファイルを利用して、いくつかの形式の映像及び音声をmuxすることができます。

さらにその下にもうちょっと詳しい説明があります。

• 任意のボックス(アトム)をエクスポートしたり、任意の位置に書き出すことができます。
• カスタムI/O APIを提供しているため、ユーザーがメモリ上に入力や出力を行う処理を記述することが可能です。
• Mux直後にプログレッシヴダウンロード用の最適化が可能です。
• ムービーフラグメントによる出力が可能です。
• インデックス済み自己初期化可能なセグメント('dash')の作成が可能です。
• テストツール的な実行ファイルで以下に挙げるストリームをmuxすることができます。
  
  • 映像
    
    • AVC/H.264 | MPEG-4 Part10
    • HEVC/H.265 | MPEG-H Part2
    • SMPTE VC-1 Advanced Profile
  • 音声
    
    • MPEG-2 AAC および MPEG-4 AAC
    • MPEG-1/2 Layer 1|2|3
    • MPEG-4 ALS
    • AMR-NB/WB
    • AC-3およびEnhanced AC-3
    • DTSおよびDTS-HD

上の方は何を言っているのかよくわかりませんが、最後の「ストリームのmux」のところは理解できます。

L-SMASH自体はソースコードのみの提供で、公式なバイナリは配布されていません。コンパイルするにはC99のコンパイラが必要ですが、Visual C++（2017）のC99サポートは不完全なためコンパイルできるかどうかはわかりません。ソースアーカイブをダウンロードして展開すると L-SMASH.sln などのファイルがありますが、config.h がないとか lsmash.def がないとかのエラーが出てコンパイルはできませんでした。それ以上は調べていないので不明です。

L-SMASH WorksはこのL-SMASHにffmpegやlibavを使用して動作するaviutlなどで利用できるプラグインです。MSYS2とMinGW-w64などを使ってコンパイルされています。L-SMASH Works r935 release2では、L-SMASHがr1474、ffmpegが4.0.2でNVDECが使える（はず）とのことです。

L-SMASHのソースツリーをみると、boxdumper、muxer、remuxer、timelineeditorというのがあります。L-SMASH Worksではこれらがコンパイルされたものがありますので、単独で起動してみると、

boxdumper : L-SMASH isom/mov structual analyzer rev1474 f963b5a
muxer : L-SMASH isom/mov multiplexer rev1474 f963b5a
remuxer : L-SMASH isom/mov re-muliplexer rev1474 f963b5a
timelineeditor : L-SMASH isom/mov timeline editor rev1474 f963b5a

と出てきますが、それぞれが行うこと（あるいは行わないこと）が今ひとつわかりません。なので実際に使ってみます。

boxdumperは動画の構造を解析するツールで、構造解析した結果をテキストで書き出すものです。MP4ファイルを食わせてみると、以下のような出力を行います。

timelineeditorはMP4ファイルのタイムラインを編集するためのツールのようです。上のキャプチャにあるtimecodeなどをいじるためのもの、なのでしょうが、ドキュメントがないのでよくわかりません。たぶん規格にあたればわかるんでしょう。

muxer/remuxerですが、解説しているページを見つけました。Mux? Demux? Remux? Huh?です。

muxは要約すると2つもしくはそれ以上の信号を1つにまとめること。デジタルメディアファイルの世界では映像と、1つまたはそれ以上の音声トラック、字幕トラックをまとめることです。その他にもチャプタートラックなどもあります。

demuxはその逆で、muxされたファイルからストリームを分離します。

remuxは分離したものを再度muxすることです。なので、muxerはtimescaleなどを指定できますが、remuxerはできません。また、muxerは出力フォーマットを指定できますが、remuxerは指定できません。

いわば、muxerは分離されたビデオトラックとオーディオトラックを合成（マルチプレクス）するもので、remuxerはさらに追加でオーディオトラックを合成するときに使うもの、ということなのでしょう。

なので、すでにあるMP4ファイルにチャプターや字幕を「追加」したいときにはremuxerを使えばいいということです。

鉄製品の錆落とし。その2

鉄製品の錆落とし。では、サンポールを使ったらどうなるのかをちょっと考察してみたわけですが、サンポールの主成分である塩酸は酸化力が非常に強く、錆は落とせてもそのあとすぐにまたオレンジ色の錆が出てきてしまうため、洗浄後はよく水で洗いでからすぐに水置換性のオイルを塗るなどの対策が必要です。

一方で市販の液体錆落としはリン酸を使うものがけっこうあるようです。モノタロウなどで扱っている鈴木油脂工業の液体サビおとし S-012などがそうで、リン酸とグリコール系溶剤、非イオン系界面活性剤が成分です。

リン酸によって錆を落とすと、その後リン酸鉄の被膜が表面にできるためにすぐには酸化しにくくなります。この皮膜を生成する処理を「リン酸塩皮膜処理またはパーカライジング」といいます。

そういえば小学生の頃、御徒町にあったMGCのモデルガンショップでガンブルーという小瓶の液体が売られていて、それを購入してモデルガンに色付けしたことがありますが、たぶんそれもリン酸の水溶液がベースとなっていたのでしょう。このとき生成されるのがリン酸第一鉄で、酸素に触れると黒鉄色に変化します。

大きいものや錆を落としたい鉄の量が多いときには廃糖蜜を使うといいようです。
大きいペール（漬物用の樽など）に廃糖蜜を1:10で水で薄めたものに、錆びた鉄を数日から数週間浸けておくことで錆が分解されリン酸塩皮膜が形成されます。廃糖蜜はサトウキビやテンサイなどから砂糖を精製したあとの副産物で安く手に入ります。

ボール盤とバイス（万力）、ちょっとどうなのよというくらいに錆びてしまったのがあるので、近いうちに錆取りしてみようと思います。さすがに廃糖蜜を使うのは場所もないので、上記の液体サビおとしを使って、モルタルを練るのに使ったトロ舟で刷毛塗りしてしばらく放置してからやってみようと思っています。

Inkscapeでの部分印刷の方法。

Inkscapeで作成したA0サイズのデザインの一部をA4で印刷したいときの方法のメモ。

ダンボール箱への印刷をデザインするのに、箱自体は試作したのだけれど印刷をどうしようかと思ったときにどうやるんだっけと思ったのがきっかけです。

箱なので六面あるわけですが、印刷デザインは版下1枚なので箱の展開図と同じサイズになります。すると大判プロッタでもなければ印刷できません。でも、それぞれの面の部分がA4に収まるなら分割して印刷すればいいわけです。a
以下の方法ではレイヤーを動かすので、オリジナルファイルで作業するのは危険です。必ず印刷用にコピーするなりして作業します。

1. 印刷するSVGファイルを開きます。
2. 「ドキュメントのプロパティ」でサイズをA4にします。すると図面上にA4サイズの枠が出てきます。
3. 印刷したい部分をその枠の中に移動します。複数のレイヤーに分かれている場合にはレイヤーごと移動します。
   上記の例なら、ダンボール箱の展開図をレイヤー0、印刷の版下をレイヤー1とした場合に、次のようにします。
   
   1. 印刷用にレイヤーを作成します。印刷レイヤーとします。
   2. レイヤー0でCTRL+Aで全選択、CTRL+Cでコピーし、印刷レイヤーに切り替えてCTRL+ALT+Vで同じ位置に貼り付けます。
   3. レイヤー0を非表示にします。
   4. レイヤー1でも同じことをします。
   5. 印刷レイヤーで全選択して、先ほどのA4枠の中に印刷したい部分を動かします。
4. プリンタアイコンもしくは印刷メニューから印刷します。
   このとき、もしかしたら正常に印刷できない（プリンタドライバが描画できない）部分があるかもしれません。そのときは印刷したい部分をA4の枠に入れた状態でPDFとして保存します。そしてPDFファイルを印刷します。

.aiファイルをInkscapeで開くときの覚書。

Inkscapeで.aiファイルを開こうとしたら、開けるファイルとだめなファイルがあったので検索しました。

Inkscape edits to an SVG file, which was originally created in Adobe Illustrator, are lost when importing back into AI

That's because Adobe cheats. It creates a valid SVG, but apart from the SVG code it also writes to the file, in encoded binary form, the entire AI-format source file of the image. Inkscape, of course, edits the SVG part of the image and leaves the encoded binary untouched. But when you import the SVG file back to AI, it completely disregards the SVG code with its edits and reads directly from the encoded AI binary. Therefore, any SVG changes are lost. To work around it, in Inkscape open the XML Editor and remove the non-SVG elements (everything not with the svg: prefix in its name, usually towards the end of the tree). If you need to do this job repeatedly you may consider using some XSLT-based automation. Alternatively, when exporting SVG from Illustrator, uncheck the options "Preserve Adobe Illustrator Editing" and "Optimize for Adobe SVG viewer". If you're using an Inkscape version higher than 0.92.3, Inkscape automatically removes the extra data from Adobe upon saving as SVG.

これを翻訳したものが以下です。

Adobe Illustratorで作ったSVGファイルをInkscapeで編集して、それをAIでインポートしたら編集結果が失われた

これはアドビのチートです。AIは有効なSVGファイルを作成するけれど、SVGコード以外の部分にもエンコードされたバイナリの形でAI形式のデータを書き込んでいます。Inkscapeは当然ながらSVGの部分を編集しますが、エンコードされたバイナリ部分には手を触れません。ところがそのSVGファイルをAIにインポートするとき、編集されたSVGコードの部分は完全に無視されてエンコードされたAI形式のバイナリを読み込みます。そのためSVGに加えられた変更は失われます。これを回避するには、InkscapeでXMLエディタを開き、非SVGエレメント部分を削除します（svg:プレフィクスで始まっていないツリーをすべて）。この作業を繰り返す必要がある場合には、XSLTベースの自動化を検討することもあるでしょう。もしもInkscpaeの0.92.3よりも上のバージョンを使っているなら、InkscapeはAdobeのデータをSVG保存時に自動的に削除します。

だそうです。
0.92.3は安定版としてダウンロードできますが、AppVeyorで自動的にビルドされているWindowsバイナリをインストールすれば、SVG保存時に自動的に削除されるようです。

AppVeyorビルドをダウンロードするには、

1. AppveyorにあるInkscapeのWindowsビルドのリストを参照します。
2. リストの中で、以下の条件を満たす最新のエントリーを探します:
   
   • 左型に緑の線があるもの（ビルドが成功したもの）
   • 右側にある名称が 0.92.x-1234 になっているもの(個人的ブランチやマスターではなく、0.92.xブランチ）
3. その説明部分をクリックします。


4. "Environment: MSYSTEM=MINGW64" をクリックします。


5. ダークカラーのターミナルボックスの上の右側にある "Artifacts" をクリックします。


6. 7zip ファイルをダウンロードします。


7. 7zアーカイブを展開できるプログラムで展開します。（7zipなど）


8. Inkscapeフォルダにある inkscape.com をダブルクリックしてInkscapeを起動します。

だそうです。 ちなみに現時点での最新0.92.xは 0.92.x-2328 のようです。ダウンロードしたら inkscape-0.92.3_2018-11-25_5aff6ba-x64.7z というファイル名でした。

ただ、そもそも開けないのはなんでなのかはわかりませんでした。AIのバージョン？

紫外線LED。

UV硬化型レジン。 ではPADICOのUV-LED Smart Light miniを一緒に購入して使っているのですが、

• タイマーが1分と2分しかない
• コンパクトだが設置が不安定

ということがあり、もう少し光の強いのを自作するにはどうすればいいか調べてみました。

Yahoo!ショッピングにLEDジェネリックというショップがあり、ここで3WクラスのUV-LEDを扱っているようです。またそのクラスになると放熱も考えなければいけないのですが、面実装LED実装用のアルミ基板と、そのアルミ基板に取り付ける小型ヒートシンクもあるようです。

これに定電流源とタイマー用のPICマイコン、スイッチを組み合わせればわりと簡単にできそうです。

MP4のチャプター名。

MP4ファイルにあとからチャプターを打つ。 では単純に連番でチャプターを打っていました。スクリプトの方もそれしか考えておらず単純にチャプター名は連番にしていたのですが、TMPEGEnc MPEG Smart Renderer 5では（というかおそらく他の編集ソフトでも）チャプターに名前をつけることができるのがわかりました。

たとえばあるビデオでは、導入部 - オープニングテーマ - サブタイトル - Aパート - アイキャッチ - Bパート - エンディングテーマ - 次回予告 などというふうに別れているとき、その説明部分まで含めてチャプターを打つことができるようです。

ちょっと手元のソースで試しにやってみたら、次のような感じになりました。

チャプター名がない場合:

0
300
2100

チャプター名がある場合:

0

300
#Name=オープニングテーマ

2100
#Name=Aパート

そしてそれをエンコード時に合成してやると…なんとVLC Media Playerでは文字化けしてしまいました。一方、MPC BEではちゃんと読めます。
文字エンコーディングの問題かもしれないと思い、チャプターファイルをUTF-8に変えてから再度合成してみます。

今度はVLCでもMPC BEでもちゃんとチャプターリストが日本語で表示されました。どうやらチャプター名はUTF-8でつければいいようです。

ちなみに、手元にあるプレイヤーソフトのCyberlink PowerDVD 17ではこのMP4のチャプターは扱えないらしいことがわかりました。さらにはChromeCastでもチャプタージャンプはできないようです。もしかしてチャプターというのは規格化されていないのでしょうか。

不思議に思ってPowerDVDで市販BDを再生してみると、ちゃんとチャプタージャンプできます。PowerDVDからChromeCastに再生させたらテレビのリモコンからチャプタージャンプできるのか試そうと思ったら、どうやら市販BDはChromeCastへ飛ばせないようです。DLNA（DTCP-IP）とかAACSとかの関係なんでしょうか。

余談ですが、ついでに調べてみたらDLNAは2017年1月5日に解散しているようです。また "ChromeCast DTCP-IP" で検索しても、ピンとくるものはなさそうなので、やっぱりその関係でしょうか。

ともあれ、TMSR5でチャプターの keyframe ファイルを作成したら、それをUTF-8でチャプター名も入った chapter.txt ファイルに変換してやればVLCでもMPC BEでもチャプター名が扱えそうです。

ということで、以前に作ったmakechap.pyを改変中です。

一方で、mp4chapsというツールを見つけました。mp4v2というツール群に入っているそうです。バイナリもあるようですが、リポジトリから最新（といっても2015年のようですが）をダウンロードしてコンパイルするのがいいかと思います。

それからMP4のチャプターファイルについてというページでチャプターファイルの形式について触れられています。

00:00:00.000 チャプター名1

の形式と

CHAPTER01=00:00:00.000
CHAPTER01NAME=チャプター名1

の形式があるようです。

現在のスクリプトは後者の形式で出力するようにしていて、これでちゃんとチャプターが打てているのでこの方向で考えてみます。

USB MIDIインタフェースを買ってみた。

Windows10でMIDIファイルを使う。でMuseScore 2とサウンドフォントを使ってMIDIの曲を演奏するというのをやりましたが、ちょっと興味が出てきたのでUSB MIDIインタフェースを買ってみました。

AmazonにProster USB MIDI ケーブルというのが999円で売っていたのでこれを調達。早速MU-100を引っ張り出してみます。
PC側はWindows 10 Proですがケーブルを挿したら素直に認識されました。そのままMIDI側は、MU-100のMIDI OUT端子にケーブルのMIDI INを、MIDI IN端子にケーブルのMIDI OUTを接続します。

MuseScore 2を起動して設定を開くと、MIDI Inputのところに "MMSyste,USB MIDI Interface" というのがあり、Outputのところでも選択できるようになっていました。

その下に "JACK オーディオサーバー" というのがあるのが気になりますが、とりあえず先に進みます。

ちなみに、MuseScore 2は起動時にMIDI機器をチェックするようで、MIDI Inputを使うためにはMuseScore 2の起動前にMIDI機器の電源を入れておくことが必要なようです。

無事つながって、先日入力したジムノペディも演奏できたので、公開されている他の曲を演奏したらどうなるかな、と探してみました。
MuseScoreのフォーラムには結構たくさんの人がアップロードしていて、ユーザ登録すればダウンロードできるようになっています。

早速 "Zen Zen Zense"（RADWINMPS） をダウンロードしてMuseScore 2で読み込んでみました。

これをMU-100で演奏させてみると…。

まずどうやら公開されている曲はGeneral MIDI 1規格を前提としているようです。一方、YAMAHAのXG規格は音色や楽器のマッピングが違っているところもあるので、GM音源で作られたMIDI楽曲をXG音源で再生すると変な感じになることがあります。
MU-100ではGM互換のTG-300モードというのを持っていて、そのモードに切り替えればなんとか再生はできます。しかしながら、GM1規格はRolandのSC-55mkIIをリファレンスとしているのでその音色を基準にして割り当てられていること、TG-300は音色はSC-55mkIIと異なるものも多いことなどがあって、曲によっては違和感バリバリなものもあります。

それからどうも音符の長さがばらついているようです。Windows上でサウンドフォントを使って再生するとなめらかに再生できるのに、MIDI OUTから出力してMU-100に演奏させると音符の長さが微妙に長かったり短かったり、ウッと詰まってみたり走ってみたりという感じになります。そういえば昔のソフトウェアMIDI音源でもそんなことあったっけとか、MIDI THRU使ってつないでもタイミングが微妙にずれたりしたっけとか思いだしたり。

ちなみにこのギクシャク感は、MIDI Outputのディレイ設定を5ミリ秒とか10ミリ秒とかにしてやるとなめらかになります。チャンネル（楽器）数が多くなってきたらもう少し増やしたほうがいいかもしれません。

キーボードは持っていないしそもそも弾けないので、入力は試していません。VL-70m＋WX11で入力できないかしら。

ETCマイレージ。

ふと気になったのでメモ。けっこう高速自動車道の料金も変わってきているようなので。

ソースは平成28年4月1日から、首都圏の高速道路料金が変わりました。

まず首都圏の高速道路料金から。平成28年（2016年）4月1日から首都圏の高速道路料金の計算方法が変わる（他の路線と同様になる）こと、ただし当面は緩和策として旧料金を上限とすること、ETC2.0搭載の場合には料金割引を導入することがアナウンスされています。

たとえば中央自動車道の均一区間（起点の高井戸ICから八王子ICまで）では、

• 都心発着の場合: 旧料金が620円 → ETCはそのまま620円、ETC以外は980円
• 都心通過の場合: 旧料金が620円 → ETCおよびETC以外ともに980円

となっています。ここでいう都心は首都高速と外環道のことです。また通過とは、中央道（均一区間）から首都高速を経由して東北道など別の路線に入ることを言います。

で、よくつかう国立府中から首都高9号木場出入り口では、

• ETCなし: 2280円（980+1300）
• ETCあり: 1440円（620+820）
• ETC深夜割引: 1250円（430+820）

となります。中央道区間は17km、首都高区間は20.6kmになります。


また平日朝夕割引と休日割引は首都圏近郊なので対象外です。


ETCマイレージ、首都高速はマイレージサービスをやっていません。が、NEXCO中日本はけっこうポイント付与率が高いようですね。支払い金額の10%のポイントが付与されます。
ポイントの還元は1000、3000、5000ポイントが溜まったら交換可能で、1000ポイントだと500円分、3000ポイントだと2500円分、5000ポイントだと5000円分になります。
1000ポイントは還元率が低いので、3000ポイント以上で交換するのがいいですね。

PythonでのWikiエンジン。

ドキュメント（に限らず、メモでもなんでも）を、のちのち検索性よく管理して、内容を簡単にアップデートできる、追記もできる、段落とか構造的なテキストにまとめておける、という点で、現状一番よさげなのはWikipediaがいちばん有名だけれどWikiWiki Webでしょう。

日本ではかなり昔からPukiWikiが有名ですが、自分はTWikiではじめました。もうほんとにごく初期の頃ですね。TWikiのAnnounceメーリングリストを購読し始めたのが2005年5月です。動かしたプラットフォームはNetBSD+Apacheで、WikiWiki記法に慣れるために英文のページをどんどん日本語に訳していたのを思い出します。

実はNeovimでPythonコードの品質やエラーを指摘してくれるALE (Asynchronous Lint Engine)というのがあって、そのドキュメントは英語で書かれているので、README.MDをダウンロードして自分用に翻訳しながら設定を詰めていこうかな、と思ったときに、そういえばこういうのってWiki使えば楽だよなぁ、と思いだしたのでした。

Wikiと呼ばれているシステムは、もともとがWikiWiki Webというアイデアから出ていて、ラクダ記法の単語（CamelCase）をキーワードとして認識し、そこにリンクを繋げられる（新しいページを作れる）というところから始まっています。さらに段落や箇条書き、引用、表の作成などのWikiWiki記法、索引、強力な検索機能などなど、ストレスなく記述していくための工夫が随所にあるのがWikiWikiの特徴です。

そうして書き溜めたTWikiのページがまだ手元にアーカイブとして残してあってかなりのページ数になっていますが、いまさらTWikiでもあるまい（PerlからPythonに切り替えたい）ということもあり、PythonベースのWikiエンジンはどうなってるんだろうと気になったのがこの記事のきっかけ。

同様に、いまさらPython2kではあるまいということもあり、Python3kで動くWikiWikiエンジンをまとめてみます。自分用のメモなので、自分の使い方を主軸にしているので過不足あるかと思いますが……。

DjangoベースのWikiアプリケーションでPython3k対応しているのは3つ。

• django-wiki
  最新版stableは2018年10月25日の0.4.2。ライセンスはGPLv3。バグ対応などのコミットは行われている模様。
• Waliki
  最新版は2017年3月26日の0.8.1。ステータスはβ。BSDライセンス。2018年5月2日にDjango2.0への対応が行われているが、それ以外は止まっている模様。
• django-wakawaka
  最新版stableは2016年11月26日リリース。githubをみても、以降のアップデートは行っていない模様。MITライセンス。

その他に、PythonWikiEnginesのページにまとめたものがあります。

• ZWiki
  ZopeベースのWikiWikiエンジン。過去にabuse被害がひどくて開発は止まっている？
• MoinMoin
  どうやら現在一番開発が活発そう。最新版は2018年9月8日の1.9.10ですが、githubでは2.0+の開発が進んでいるようです。

ちなみにWikiMatrixというサイトで多くのWikiWiki Webの比較を行っているので、ここも参考に。

ここにはWikiエンジン選択のウィザードがあって、まずウィザードで絞ってからいろいろな機能を比較できるというメリットがあります。
これによると、自分の用途にあいそうなのはやっぱりMoinMoinかな。

エクスプローラ上でPythonスクリプトにドラッグ&ドロップする。

Windows上では、たとえばテキストファイルをPythonスクリプトに食わせて処理させたい場合、テキストファイルをドラッグ&ドロップ（以下DnD）しようとしてもスクリプトがハイライトされず、DnDを受け付けません。

検索してみると、ベクターでDrop on Scriptというものがあるようですが、これはWindows2000までで、インストールしようとするとWindows 10は拒否してきます。32bitアプリだからというわけではないでしょうから、署名なのかマニフェストなのかそこらへんでしょうか。

どうやら一般的にはDnDを受け付けるバッチファイルを作成し、バッチファイルから引数をPythonスクリプトに渡す、ということがされているようです。

ですがそれだけのためにバッチファイルを書きたくないし、ファイルが増えるのもゴメンです。できればショートカット1つで済ませたい。

参考までにバッチファイルでやるときは、%* を使います。これですべての引数をPythonの sys.argv に渡せます。ファイル名はフルパス名で与えられるので、必要に応じて os.path などを使って加工します。


が、次のような使い方をする場合には面倒です。

data--+--1
      +--2
      +--3
      +--4

のようなディレクトリ構造を考えます。

1から4のディレクトリにはそれぞれ処理したいファイルが格納されています。すべてのディレクトリで同じように処理したい場合には、glob を使ってディレクトリとファイル名を展開すればいいですが、たとえば1と2だけ処理したい場合にはその手は使えません。

さらに1のディレクトリの中で複数ファイルがあって、その中のひとつだけを処理したい場合にはDnDでPythonスクリプトに食わせたいという場合があります。
そうすると、それぞれのディレクトリにスクリプト（とバッチファイル）をコピーして、処理したいファイルをDnDすればいいということになりますが、ここでスクリプトを変更したいという要求が出ます。すると、コピーしたすべてのスクリプトを忘れずに変更しないといけませんが、変更し忘れることもありえます。

そのため、以下のようなディレクトリ構造にします。

data--+--1
      +--2
      +--3
      +--4
      +--script

そしてスクリプトをscriptディレクトリに置いて、1から4にはスクリプトへのショートカットを作成します。そしてショートカットのプロパティの作業ディレクトリは "." にしておきます。すると、scriptにあるファイルを変更すれば済むかたちになります。
DnDで引数を渡したい場合には、バッチファイルを作成してスクリプトを呼び出す形にします。

バッチファイルの記述を以下のようにします。

script/DnD.bat:

@echo off
python ..\script\process.py %*

相対パスで呼び出しているのは、他のディレクトリでもちゃんとPythonスクリプトを参照するためです。こうすることで、このバッチファイルのショートカットのみを1から4の各ディレクトリにコピーしてやればいいことになります。
ただし、これがさらに改装が増えたりした場合には絶対パスに変えたほうがいいでしょう。

別の方法として、pyinstallerを使ってEXEファイルにしてしまうという方法があります。EXEファイルはDnDを受け付けますし、そのショートカットも同様ですので、これでも期待した動作ができるでしょう。pyinstallerに "--onefile" オプションを付けて実行すると、必要なモジュールまで含めて1つのEXEファイルを生成してくれます。

難点としては、Pythonスクリプトを変更するたびにpyinstallerでEXEファイルを作り直す必要があること、生成したEXEファイルが大きいこと、pyinstallerが作成する dist ディレクトリからscriptディレクトリにコピーしないといけないこと、などがあります。

やっぱりバッチファイルのショートカットが一番ラクですかね。

neovim-pythonからpynvimへ。

どうやら何日か前にNeovimでのPythonモジュールの呼び出しが若干変わったようで、Python-neovimを pip -U したあとで ":checkhealth" したらエラーが出るようになりました。

検索してみると :checkhealth failed after upgrade module neovim to 0.3.1 (on python 3.7.1) #366 というのがあって、python-neovimがpynvimに変わったよ、でもpython-neovimがインストールされてるとエラーになるよ（意訳）、とありました。どうも pip install -U neovim するとneovimを削除しきらずにpynvimをインストールして、なにやらコンフリクトっぽい状況になるようです。

解決方法は簡単で、いったんpython-neovimとpynvimを削除してからpynvimをインストールし直す、だそうです。
うちもそれで直りました。ちなみにneovimバージョンはnightlyの0.3.2-913でPythonは3.7です。

カバンの補修。

使っていれば擦れてくるカバンのカド。コロンブスのアドカラーで補修しました。

以前は小皿を使ってやったんですが、、今回やっとジョイフル２の画材コーナーでパレットを見つけて買ってきました。パレットだけってなかなか売ってないんですよね。絵の具セットならあるんですが、別に絵の具が欲しいわけじゃないので探してたんです。

さて早速開始です。これは愛用している青木鞄のラガードNevadaのミニダレスバッグです。電車の座席に座ったときに、膝の上においても横にはみ出さないサイズ。書類は折らないと入らないですが。
こうしてみると結構擦れてますね。

コロンブスのアドカラーと買ってきたパレット。パッケージに入ってるのはアドベースで、キズ補修用です。今回使用するのはコイチャ、クロ、アカかな。

よく見ると芯材が見えてきています。これはやばい。600番のペーパーでちょっと荒らしてみたあとですが、これは難しい。でもそのままやっちゃいます。

調色。モリモリにならないように水で適当にのばして、しっかりと混ぜていきます。

ささっと塗り塗り。いい感じに塗れてる気もするし、ちょっと濃いかなという気もしますが。

別のところも擦れを見つけたので、ペーパーをかけてから塗り塗り。

こんなもんでしょうか。触ってみるとやっぱり革の部分との肌触りの違いがあるんですが。しっとり柔らかい革に対して、ゴワッとしたビニールっぽい感じ。でもまあここは触る場所じゃないのでいいでしょう。

ついでにウォーキングというかキャンプモカのつま先の上部分が擦れていたのでこれも補修。

またちょっと色を整えて、今度は黒多め。

乾くとこんな感じ。ブラシをかけるともうちょっと馴染む感じになるけど、これはもうわかりませんね。

UV硬化型レジン。

通常は2液混合型が多い工作用レジン（樹脂）ですが、1液タイプだとUV硬化型と熱硬化型があるようです。

そのなかでもUV硬化型はアクセサリなどを作る人たちに向けたお手軽な製品が出ています。たぶん有名なところではパジコの太陽の雫と星の雫だと思うので、ちょっと比較してみました。どちらもハードタイプを比較してみます。

項目	太陽の雫	星の雫
容量	25g	25g
成分	アクリル系紫外線硬化樹脂	アクリル系光硬化樹脂
推奨ライト	UVライト(365nm?)	UV-LEDライト(405nm) UVライト(365nm)
硬化時間
UV-LEDライト	??分	30～90秒
UVライト	2～10分	2～4分
太陽光	10分～1時間	30秒～10分
価格(税別)	1,200円	1,500円

並べて比べてみると、星の雫のほうが硬化時間が短くてその分高いように見えます。また通常の蛍光灯でも若干の硬化反応があるようなので、蛍光灯照明のもとで作業するなら太陽の雫のほうがよいのかもしれません。
それと、屋外に出したり長時間露光させるときにホコリなどが入り込まないようにUV-LEDスマートライトミニなどを用意するのもいいですね。値段お手頃な感じですし。

ということで早速ヨドバシ・ドット・コムで購入してみました。
購入したのは「太陽の雫ハードタイプ 25g」とUV-LEDスマートライトミニです。ちょっと都合上写真は載せられないですが。

太陽の雫はアクリル系なので、サラサラではなくドロッとした感じです。が、パテのように盛ることはできず、粘性の液体っぽい表面張力があります。

一方、UV-LEDスマートライトミニですが、こちらはごく普通のUSBアダプタで点灯可能です。コネクタはマイクロBですが、最近のスマホなどはたいていUSB充電なので共通で使えると思います。

さて、たらした液体の上にUV-LEDを角度を調整してかぶせ、ボタン長押し（120秒）して点灯を確認してから紫外線が目に入らないようにダンボール箱を逆さにしてかぶせます。

2分後にはUV-LEDは勝手に消えているので、しばらく放置してから恐る恐る触ってみると、ちゃんと硬化していました。が、ちょっと弾力のある感じ。なので追加で2分照射しました。しっかりと硬化して、艶のある透明の感じに仕上がりました。何回かやってみましたが、2分を1回だとまだちょっと柔らかいので、2分を2回やるのがよさそうです。

もしかしたら、アクリル製品の小キズやガラス面などのちょっとした欠けなども、ヘラなどで塗布して硬化させれば結構いい感じに仕上がるかもしれません。

Google Homeで家電制御…。

家電関係のショーやフェアではスマートホームというかIoT絡みでのホームオートメーションというか、音声でライトが点いたりテレビのチャンネル変えたりなんていうのをやっているけど、誰かに何かをさせるには、そのための通信を行ってコマンドや応答のやり取りが必要になります。

そのためには有線無線関係なく、それぞれの機器が通信を行うための待機電力が増える、という問題もありますがそれは置いといて。

じゃあ家電とコントローラはどんなプロトコルとどんな手段で通信しているのだろうと、ふと思ったのであります。

ZigBee、BLE（旧Wibree）、DigiMesh、Z-Waveなどなど、低消費電力の無線規格はありますが、ソフトウェア面にはあまり注目していませんでした。

OSI参照モデル的には、Threadはトランスポート層とネットワーク層を担当し、物理層とデータリンク層は802.15.4を利用するようです。もともと802.15.4はIPv6とよく似た形でパケットの形式を定義していて、SourceやDestinationアドレスもIPv6に近い形式（6LowPAN）で指定するようになっています。そのため、LANとの親和性も高く、TCP/IPネットワークとのゲートウェイもかなりシンプルになるはずです。

Thread上でのデバイス開発は、Developing IoT Devices with Threadにありますが、それをオープンソースとして実装したOpenThreadというのがあるようです。
これをデバイス上で動かすことができれば、あとは802.15.4無線モジュールを持ってきて組み合わせてやればよい、ということでしょう。
もちろん電波で通信する関係上、セキュリティは重要になってきますので、その部分もしっかり見ないとですね。

ちなみに上記4つの無線規格のうち、BLEを除くと他の3つは802.15.4規格の上に構築されていたと思います。また、Digi Internationalが802.15.4のモジュールを国内の認証を取得して販売しています。その他にもロームなどが出しているようです。

ただ、802.15.4も電波を飛ばす部分がそれなりに電流を食いますし、受信に限っても送信ほどではないですが食いますので、メッシュネットワーク的には時刻同期を組み合わせた間欠通信かつ輻輳制御ということになるんでしょうか。

実際にはアプリ開発者はそこまではやらずに足回りは通信デバイスメーカに任せるんでしょうけど。

ということで、実際の家電への実装はOpenThreadを見ればそれなりに分かるということですね。

ちょっと眺めてみると、まず説明のところで、OpenThreadはNestが開発したものをBSDライセンスに準じた形のBSD 3-Clause "New" or "Revised" Licenseで公開している、とのこと。その目的は、多くの開発者が使えるようにすることで様々な製品の開発を加速することにあるようです。

また、

a Thread Certified Component, implementing all features defined in the Thread 1.1.1 specification, including all Thread networking layers (IPv6, 6LoWPAN, IEEE 802.15.4 with MAC security, Mesh Link Establishment, Mesh Routing) and device roles, as well as Border Router support.

だそうで、このOpenThreadは上記で通信デバイスメーカに任せるのではと書いた部分も含んでいるようです。

そういえばふと気になったので調べてみたら、かつてEM250というZigBee用のSoCを開発した米国Ember Corp.は、2012年にSilicon Laboratories, Inc.に吸収されたんですね。

余談ですが、いやらしいことに802.15.4は2.4GHzの電波を使用していて、それが無線LANの周波数とかぶっているので、無線LANの電波がバリバリ飛ぶ（たとえばYouTubeで動画を見ているとか）と電波出力の弱い802.15.4は通信障害を起こしやすくなります。また当然電子レンジにも影響を受けます。そのため、海外では700/800/900MHz帯の802.15.4モジュールもあるようです。日本では900MHzに近い帯域として950MHzを使えないかということも検討されていたようですが、現状ではまだ認可されていないかな、と思ったら920MHz帯で規格化されているようですね。

xplorer2 4.1。

Windowsを使うときには必ず使っているファイラですが、うちはデュアルペインのxplorer²を使っています。基本的にはファイラとしてしか使ってないので、あまり大したことも言えないのですが……。

そのxplorer²が9月16日に4.1.0.0をリリースし、4.0系で実装されたマクロ機能が使いやすくなったようです。

すごいらしいんだけど全然使ってないから、誰かまとめてくれないかしら。

TMPGEnc MPEG Smart Rendererのショートカットキー。

マウスで動かすよりも素早くできるので、まとめておきます。

項目	操作	ショートカットキー
移動系	次のフレーム	→
	前のフレーム	←
	次のIフレーム	Shift + →
	前のIフレーム	Shift + ←
	次のキーフレーム	Ctrl + →
	前のキーフレーム	Ctrl + ←
	次のシーン	↓
	前のシーン	↑
	開始フレームにジャンプ
	終了フレームにジャンプ
	先頭にジャンプ	Home
	末尾にジャンプ	End
	指定した時刻フレームにジャンプ	Ctrl + J
マーク系	CM候補検出	Ctrl + D
	範囲はじめ	[
	範囲おわり	]
	キーフレーム追加/削除	Ins
	クリップ分割点の指定/解除	Shift + Ins
編集系	指定範囲の削除	Del
	指定範囲以外の削除	Shift + Del
	現在位置から範囲末尾まで削除	Ctrl + [
	範囲先頭から現在位置まで削除	Ctrl + ]
	編集終了	Shift + Enter
	一つ前の操作を戻す	Ctrl + Z
	編集内容の破棄	Esc

不明なものもありますがほぼこれで網羅できているので、作業がはかどります。
とくにCMの頭出し位置などでは、Iフレーム移動で大まかに移動してから↑または↓でシーンチェンジまで移動できるので、ものすごくはかどります。マウスホイール動作も不要です。

実はテンキーに割り付けられないのかなとか考えていましたが、やりたいことはほぼ実現できているので問題ないですね。

MP4ファイルにあとからチャプターを打つ。

チャプターが打てるようになったので、もしやと思って試してみました。

まず、チャプター位置を記録したkeyframeファイル、もしくはchapter.txtファイルが必要です。
ここではtest.mp4、test.m2ts、test.keyframeを想定します。

1. TMPGEnc MPEG Smart Rendererを使っている場合、m2tsファイルが残っていればそれを読み込み、カット編集画面でCTRL+Sでkeyframeファイルを保存します。
2. 保存したkeyframeファイルをchapter.txt形式に変換します。
3. L-Smashのremuxer.exeを用意します。
   remuxer -i test.mp4 --chapter test.chapter.txt -o output.mp4
   とすれば、チャプターを打って結果を output.mp4 に保存してくれます。

ということで、これをバッチファイルにしてしまえば楽ですね。こんな感じです。

@echo off

if x%1==x goto :ERR

set MP4=%*
set BASE=%~n1

echo %MP4%
echo %BASE%".chapter.txt"

C:\Apps\aviutl\exe_files\remuxer_r1474.exe -i %MP4% --chapter "%BASE%.chapter.txt" -o temptemp.mp4
move temptemp.mp4 %MP4%
:END

このバッチファイルにMP4ファイルを食わせれば、うまいことやってくれます。

が・・・。

【悲報】VLC MediaPlayerでChrome Castに飛ばしたら、レグザのリモコンのチャプターボタンでは移動できませんでした…。

keyframe形式をaviutlで扱えるように変換する。

ビデオファイルの編集にはTMPGEnc MPEG Smart Renderer 5を使っていますが、これの出力するkeyframe形式は同じPEGASYSのTMPGEnc Video Mastering Worksなどでしか使えません。
aviutl（正確にはx264guiExプラグインなどから呼び出される muxer.exe / remuxer.exe）で扱うには、別の形式に変換する必要があります。

ということで、いつもどおりPythonでお助けスクリプトです。あらかじめ dateutil モジュールをインストールしておく必要があります。

#!python3
# -*- coding: utf-8 -*-
# vim:fenc=utf-8 ff=unix ft=python ts=4 sw=4 sts=4 si et fdm fdl=99:
# vim:cinw=if,elif,else,for,while,try,except,finally,def,class:
#
# makechap.py:
# カレントディレクトリからすべての.keyframeファイルを検索し
# 順次aviutl（muxer.exe, remuxer.exe）が取り込める形式の
# チャプターマークに変換する
#
# TMPGEnc MPEG Smart Rendereの.keyframe 出力形式
# [chap1]
# [chap2]
# ただし[chapx]はフレーム番号
# muxer / remuxer のチャプター形式
# CHAPTER01=00:03:00.000
# CHAPTER01NAME=タイトル1
# CHAPTER02=00:06:30.000
# 0CHAPTER02NAME=タイトル2

import sys
from glob import glob
from os.path import join, splitext
from os import close
from dateutil.relativedelta import *

# import pdb; pdb.set_trace()

if sys.version_info[0] != 3:
    print('This script requires Python 3')
    exit()

path = '.'
debug = 0
files = []
i = 0

files = glob(join(path, '*.keyframe'))
if debug:
    print('files:', files)

for kffile in files:
    f = open(kffile, 'r')
    outfile = open(splitext(kffile)[0]+'.chapter.txt', 'w')
    frames = f.readlines()
    base = splitext(kffile)[0]
    for frame in frames:
        i = i + 1
        rd = relativedelta(seconds=round(int(frame)*0.0333667))
        time = "{0.hours:02}:{0.minutes:02}:{0.seconds:02}.000".format(rd)
        if debug:
            print(f'CHAPTER{i:02}={time}')
            print(f'CHAPTER{i:02}NAME={i:02}\n')
        outfile.write(f'CHAPTER{i:02}={time}\n')
        outfile.write(f'CHAPTER{i:02}NAME={i:02}\n')
    i = 0
    f.close()
    outfile.close()

こうして作ったchapter.txtをチャプターとしてMP4ファイルに埋め込むには、x264guiExなどの設定パネルでチャプターを設定しておけばやってくれます。

FreeCADとクォータニオン。

FreeCADのViewではAxonometric（不等角投影）、Front/Rear、Top/Bottom、Right/Leftの7種類が標準で用意されていますが、それ以外の角度から見た図を用意したいという場合、けっこう困ります。

マウスでグリグリ動かしてうまいこといい感じの角度に持っていければいいんですが、なかなかこれが難しい。

となると、オブジェクトのPlacementプロパティのAxisとAngleを使って…という手もありますが、これもまた思うようにいきません。

ではFreeCADのPythonコンソールからやってみたらどうだろうと思ったのがこの記事の趣旨です。

Viewをツールバーのボタンアイコンやメニューから変更すると、Pythonコンソールにそのときに発行されたコマンドが出力されます。つまりこれは、FreeCADが内部でPythonを使ってモデルオブジェクトをいじっているということなんですが、たとえばTopボタンを押すと、

>>> Gui.activeDocument().activeView().viewTop()

というコマンドが発行されています。

また、たとえば先程のPlacementプロパティをいじると、それに対応した関数が呼ばれているのがわかります。

そんなことをしながらソースとドキュメントとコンソールをいじっていて、やっと見つけました。

まず、

Gui.ActiveDocument.ActiveView.setViewDirection([tuple])

です。これは視点方向を指定するコマンドになりますが、[tuple]のところにタプル形式で (X,Y,Z) を指定します。これがどうやら単位ベクトルになるようではあるんですが、今ひとつ挙動が思うようになりません。
ちなみに当然のように getViewDirection() もありますので、現在のViewの方向を知ることはできます。

この関数やviewTop()などをソースで追いかけていくと、Gui.ActiveDocument.ActiveView.getCameraOrientation() / setCameraOrientation() にたどり着きました。

このsetCameraOrientation()は、引数としてsbRotationオブジェクトを指定するようですが、ソースでは4つのパラメータを指定していました。それがおそらく SbRotation::SbRotation(const float q[4])だと思いますが、qが4つ。これがクォータニオンです。回転する3Dモデルを使うときには必ず出てくるもので、Direct3Dなんかをいじるときには避けては通れないものです。

それはともかく、Axo、Front/Rear、Top/Bottom、Right/LeftのそれぞれでgetCameraOrientation()のパラメータを確認した上で、マウスでできるだけ自分が参照したい角度に近づけて、再度パラメータを確認してみました。

自分が欲しかったのは、Axoと同じX-Yで、それを斜め上からではなくて真横から投影したものです。
それがちょっと傾いていたので、確認したパラメータをちょっといじって (0.65, 0.28, 0.28, 0.65)としてやったら、ちょうどよさそうな角度になりました。

本質的ではありませんが、実践的にはこういう方法もありかと思います。

Cygwin64 互換性のないランタイム。

KiCADのライブラリのうち、3Dモデルが1GBを超えていたので中身を見てみたら*.stepファイルが巨大だということがわかりました。

なので一括削除しようとして

find -name *.step | xargs rm

しようとしたら、エラーだよ、ランタイムの互換性がないんじゃないの、と言われました。

思い当たるのは、Git for WindowsとCygwin64をインストールしていて、パスはGfWのほうが先に参照されるようになっていること。なので、Cygwin64のfindからGfWのrmを呼び出そうとしてコケていたようです。

ご存知の通り、CygwinはWindowsのドライブを /cygdrive/c/ のような形で仮想的にマウントして扱います。一方、MSYS2（GfW含む）は /c/ という形で参照します。これまでは後者のほうが都合がよいのでGitはGfWを使用し、その他の場合にはCygwin64を使っていたのですが、上記のエラーが出てきたのでGfWはやめることにしました。

ちなみにマウントポイントの指定ですが、Cygwin64の場合には、c:\Cygwin64\etc\fstabを編集することで変更することができます。
うちの環境では

none /mnt cygdrive binary,posix=0,user 0 0
c:/cygwin64/bin /usr/bin ntfs binary,auto 0 0
c:/cygwin64/lib /usr/lib ntfs binary,auto 0 0

として、cygdriveを/mntに変更しています。

PEGASYSのVMW7でQSVの設定。

PEGASYSのTMPGEnc Video Mastering Works 7の試用版を使ってみているのですが、CPUがHaswell Refreshのi7 4790KなのでIntel Media SDKのハードウェアエンコーダを使うことができます。実はメインPCはGeForce 1060を搭載しているのでNVEnvも使用できるのですが、画質的にはまだちょっとな部分があるので、QSVを使ってみます。

実写系の素材では高精細を求めなければエンコード速度も早くて使いやすいですし、チャプターを打つのも素材の編集時に出力するようにしておけばカンタンです。ちなみに素材の編集はTMPGEnc MPEG Smart Renderer 5を使っています。こちらはちゃんと製品版。

さて設定ですが、駄文置場さんのKabeLake時代のQSVエンコード画質について考えるを参考に、概ね以下のような感じにしています。

映像エンコーダ Intel Media SDK Hardware
レート調整モード VBR(固定品質) VBV無し
パフォーマンス 標準
品質 50
音声 320

映像品質の50ですが、上記のページでは

51-(品質値x0.5)

とのことなので、50だとcrf=26相当になります。
音声については元のソースがAAC 250kbps程度のレートですが、余裕を持ってこのレートにしています。

映像品質ではLA-ICQが最も画質的によいというのはいろいろな評価で言われていますが、実写ソースだとcrf=26あたりでは「非常に細かいディテールは潰れるが気にならない程度」というレベルです。実際には、遠景のビルの窓の描写がのっぺりするとかそんな感じですが、メインの被写体が破綻してなければいいか、という場合にはこの程度です。

その他によく使いそうな指標としては、56でcrf=23相当、62でcrf=20相当となります。

Windows10でMIDIファイルを使う。

だいぶ昔にYAMAHAのMIDI音源MU-100とかMU-80とかVL-70mとかを購入しているんですが、手持ちのMIDIインタフェースがISAバスなので現在のPCには使えず、眠ったままになっています。

ちょっと商品の動画にBGMをつけたくて、パブリックドメインになった曲を楽譜入力してMIDIで演奏させればいいかなと思ったのでメモ。

まず楽譜入力ですが、評判とか使いやすさとかわかりませんがMuseScoreというソフトをダウンロードして使ってみました。しっかり使い込める知識も技量もないですがDTM素人が楽譜入力できるという点ではいいのかな、と。

楽譜に音符を置くと音が出てきます。MIDIで再生しているようで、入力した譜面をそのまま演奏できるようです。ある程度の音源も持っているようで、ピアノ、フルート、ベースなどもあります。パート譜に分解することもできるようです。

このソフトを使って、3つのジムノペディ（エリック・サティ作曲）を入力してみました。デフォルトで割り当てられている楽器はピアノです。

楽譜の入力が終了すれば、演奏ボタンをクリックして演奏できます。

MuseScoreは標準でGM音源をサウンドフォントの形で持っていて、これを使って演奏します。MuseScoreのサウンドフォントの説明によれば、

MuseScore 2.2 は General MIDI (GM) のサウンドフォント MuseScore_General.sf3 が搭載されており128種類を超える楽器とドラムセットが含まれています。

とのことです。現在のバージョン 2.3.2も2.2に準じているようです。

サウンドフォントはもともと、E-mu Systemsによって開発されたものをCreative TechnologyのSound BlasterシリーズでMIDI音源を搭載するために使用され、それが他のサウンドカードやソフトウェアでも使えるようになってきたものです。現在はPCのマザーボードには音声codecも搭載されているのでエンスー用途くらいでしか見ることがなくなりましたが、かつてはSound Blaster 16やSound Blaster Live!、またMonster Soundなどというサウンドカードがいくつもありました。
かつてはサウンドフォントをいくつかまとめたサウンドバンクという形式のファイルを、サウンドカードにダウンロードして使用したものでした。

それはともかく、MuseScoreではサウンドフォントが使えるということで、デフォルトの音源が気に入らなければ自分の好きなフォントを持ってきて使えるということです。
MuseScoreではSynthesizerの設定でサウンドフォントを追加・選択できるようになっています。

実はここではすでにサウンドフォントを追加しています。

サウンドフォントはフリーで提供されているものがネット上にいくつもありますが、CoolSoftのVirtualMIDISynthのページの下の方に簡単にまとめられています。

サウンドフォントはsfArkというアーカイバによって圧縮されて配布されているので、利用するにはsfArkをインストールすることが必要です。上記はダイレクトリンクですが、インストールする場合には必ずウイルス対策ソフトなどでスキャンしてください。

VirtualMIDISynthのページには作者のリコメンドのあるFluidR3_GMや巨大な（1.57GB！）CrisisGeneralMidi 3.01などのリンクが有り、さらにSoundFont聞き比べコーナーという素晴らしいページへのリンクもあります。

ここからダウンロードしたサウンドフォントをsfArkで展開し、%USERPROFILE%\MuseScore2\サウンドフォントというディレクトリに放り込みます。すると先程のSynthesizerのダイアログで追加できるようになります。

こうして作曲した譜面ですが、それを録音しないと動画と合成することができません。さて録音はどうしよう、Windows 10はサウンドレコーダーなくなってるし、と思ったら…。

MuseScoreではなんと、譜面を演奏した音をWAVやMP3形式でエクスポートできるようです。

見ての通り、エクスポートのファイル形式はWAV、MP3、FLAC、OGG、MIDなどがあります。試しにWAVで出力してみたら、メディアプレーヤーで再生できました。

「Windows MIDI」で検索するとドライバやVSTなどのページがたくさん引っかかりますが、自分の用途にはMuseScoreだけで十分なようです。さらにメニューやツールバーを見るとMIDI-INやMIDI-OUTなどという項目もあり、たぶんMIDIインタフェースさえ用意すれば外部MIDI機器も使えるのではないかと思います。

もうひとつ、試しにフリー素材としてダウンロードしてみた「G線上のアリア」をMuseScoreで開くと、なんと楽譜形式で表示されました。これもすごい。至れり尽くせりです。

デジカメのビデオ録画時間。

商品の撮影でEOS7Dの動画機能を使ったんですが、30分で動画撮影が自動的に終了（というか強制終了）したので、ああそんなこともあったっけと思いだしたのでメモ。

実は各デジタルカメラメーカ（に限らず、撮影機能を持った製品を作っているメーカ）は、ヨーロッパにも製品を出荷する場合にこの30分制限をかけています。

JETROより、EU 関税制度に概要がありますが、EUではデジタルカメラとデジタルビデオカメラで関税が違います。デジタルカメラには関税がかかりませんがビデオカメラにはかかります。ところが、動画撮影機能を持ったデジタルカメラが増えてきたためにビデオカメラとデジタルカメラの分類を行う必要が出てきて、以下のように決まりました。

• ビデオの画質が800x600ピクセル以上
• フレームレートが23fps以上
• 動画の連続録画時間が30分以上

この3つの条件を同時に満たす場合にはビデオカメラに分類されることになり、10.5%の関税が課せられてきました。そして各メーカはそれを避けるために、動画の録画時間を29分59秒で終了することにしたのです。

現在の状況としては、当初10.5%だったビデオカメラ関税は2017年から7.0%に引き下げになりました。
また、上記条件に該当する場合でも静止画画質が5Mpix以下でFullHD/30fps以下のアクションカメラについては、2017年11月21日に関税が廃止されたようです。

また、来年2月には日・EU EPA発効と同時に日本製デジタルカメラに対する関税は即時撤廃されます。が、これに関して動画撮影機能がどうなるのかは詳細がわかりません。

qaacでCoreAudioToolbox.dllが見つからない場合。

余計なこと抜きで要点だけ。

CoreAudioToolbox.dllはWindows版iTunesのファイルです。ですのでこれを入手するためにはiTunesから抜き出す必要があります。が、現在ではiTunesはMicrosoft Storeからしかダウンロードできないようになっていて、かついきなりインストールされてしまいます。

インストールされた場所がわからないとファイルを抜き出すこともできないため、一旦iTunesを起動してからタスクマネージャーでファイルの場所を開きます。

すると "C:\Program Files\WindowsApps\AppleInc.iTunes_12091.4.37126.0_x64__nzyj5cx40ttqa" なる場所にあることがわかりました。どうやらStoreからのアプリはこの WindowsApps フォルダに入るようです。

ここから以下のファイルを抜き出して、qaac.exeと同じフォルダに入れます。

• ASL.dll
• CoreAudioToolbox.dll
• CoreFoundation.dll
• icudt55.dll
• libdispatch.dll
• libicuin.dll
• libicuuc.dll
• objc.dll

以上です。

スチールデスクの引き出しのベアリング修理。その2

ちょっとナッターはモノタロウに注文しているのですが、付属分だけではナットが足りないかもしれないのでジョイフル本田でエビローレットナットを追加購入してきました。一般的にはブラインドナットの名称です。

ちょっとナッターも売ってましたがモノタロウより高め、かつM6のものは売り切れでした。ちなみにこれは10個入りで910円でした。

エビローレットナットは、スリーブのところにローレット加工がしてあり、ストレートのものよりは締め付けるのが楽なように見えます。スチールだから強度はアルミよりも高いはずなので、引き出しの保持にはちょうどいいかと。

エビローレットナット含むM6のブラインドナットは下穴径がφ9.1だそうですが、ステップドリルには9.1というのはなさそうで、そうなると円錐形のリーマーでちょっと削るか丸ヤスリを持ってくるか、それともルーターで軽く削ってやるかしないと入らないかもしれません。実際にエビナット外径を測ってみるとローレット部分が9mmちょうど、先端近くは8.9mmでした。

今回、φ9.0の穴を正確にあけるためステップドリルを購入しました。モノタロウの六角軸チタンコーティングというやつです。
まず10mmのところにマスキングテープで目印を付けます。それでベアリングが固定されていた穴を拡げます。

実際には脚の幅が狭いため、7mmまで掘ったところで突き当たってしまいました。なので反対側に4mmの鉄工ドリルで逃げを掘って、ステップドリルでφ9mmまで掘り進めます。

ピンぼけですがちょっとナッターにマンドレルとエビナットをセットして、掘った穴にセットしてみました。実際にはステップドリルが正確にφ9の穴を開けたのでそのままでは入らなかったのですが、そのまま回しながらちょっと揺すってやるとエビナットが入るサイズになりました。ヤスリとかは不要でした。
それからちょっとナッターのパッケージの裏が使用方法の説明になっています。そこには「マンドレルには毎回潤滑油を塗布してください」と注意書きがあるので、注油はちゃんとしておきます。

締め付け中の写真はぼけぼけで使えませんでしたが、自転車用に愛用しているSWISS TOOLSの5mmのアーレンキー（六角レンチ 柄の長さ17cm）を使いました。ローレットナットとはいえスチールなせいか、締め付けるのにかなり力が必要で、短いやつだとすごく大変でしたが、長いと楽です。およそ2.5回転で締まりきりました。それ以上締めるとマンドレルが逝ってしまいそうでした。ちなみにパッケージの裏にかしめ量の参考表があって、厚み1mmで4回転、2mm厚で3.2回転、3mm厚で2.5回転となっています。
締め終わったら17mmのメガネレンチを外さずに、アーレンキーで逆方向に緩めてからちょっとナッターを外します。

ちなみに手応え的には締めればどんどん閉まるのですが、最初はグラグラしていたちょっとナッターが固定され、回転遊びがなくなったところで十分に締まっていると判断しました。

最後にねじ付きの樹脂ベアリングをねじ込んで終了です。しっかりと固定されました。

ところでちょっとナッターですが、本体はネジの切っていない六角ナットで真ん中にゴムリングがあります。同心円の筋が入っている方をエビナット側にしてセットします。

ところで、右側の六角穴付きマンドレルなんですが、どうも普通の六角穴付ボルト M6x30（全ねじ）に見えるんですけど。
たぶんこれ、ネジ山が逝っちゃったらボルトを買ってくれば使えると思います。

スチールデスクの引き出しのベアリング修理。

これから材料を揃えるので、まずは忘れないようにメモ。

会社のスチールデスクですが、引き出しの部分の支えになっているベアリングローラーがボキッと折れてしまいました。ちょっとよろけて引き出しに手をついた拍子に。
そうすると引き出しががくんと下がって、持ち上げないとちゃんと閉まらないようになってしまいます。

元のベアリングは引き出し両脇の脚の部分にリベットで固定してあり、1.5mm厚の鉄板です。最初はここに2mmから3mmの薄型ナットを瞬間接着剤で固定して、ネジ付きのベアリングをねじ込めばいいかと思ってたんですが…。

購入したのは、モノタロウの樹脂ベアリング DR-B（ネジ軸タイプ）TYPE7 トップベアリング製です。直径22mmの樹脂ベアリングで、M6のネジ軸となっています。ネジは並目で1mmピッチ。ところが薄型ナットは厚さ2mmの細目になっていて、ちゃんとハマりません。

しかたないので、ドリルで6φの穴を開けてそのままベアリングを差し込んで、宙ぶらりんで使用しています。ないよりマシ、という程度。

ちょっと気になってはいたので、ホームセンターでいいものないかなと眺めていたら、よさそうなのがありました。ハンドリベッターという工具で、片面からリベットを打ち込んで反対側をカシメることができる工具です。ハトメパンチのように両側から挟む必要がなく、片側からリベット打ち込んで固定できるもののようです。が、そこでM6のネジをねじ込めるリベットなんてあるんだっけ、とリベット自体を確認してみると、ハトメのような穴開きではなくてやっぱりリベットはリベットでした。

だめかー、と思いつつ同じ棚を眺めていると、「エビナット」というのを見つけました。ロブテックスという会社の製品で、ナット＋リベットの両方の機能を持ったブラインドファスナーです。筒状になっており、中が雌ねじになっています。これならいけそうです。
そしてこのエビナットを固定するツールがハンドナッターです。M6まで対応するのがトラスコ、SK-11、ロブテックスなどから出ています。これで薄板にナットを固定でき、ベアリングをねじ込むことができそうです。ただし、片手のものはスチールの6mmは厳しいようです。
その他、ロブテックスから「ちょっとナッター」という簡易工具が出ています。これは六角レンチとめがねレンチで締め付けていくタイプのようですが、安価なのが魅力です。

ナットの方では、ロブテックスのエビナット、新潟精機のブラインドナット、ポップリベットのポップナットなどがあります。エビナットではKとDの2種類があり、違いはフランジ（縁）の幅がDタイプは大きくKタイプは小さいということのようです。思うに、ナットを固定する板の強度に応じてDかKを選べということでしょう。プラスチックなどに固定する場合にはフランジの大きいほうがよいと思われます。

エビナットなどの構造としては、奥の方に雌ねじが切ってあり、ボルトを入れて締め込むことで手前の筒の部分が外に潰れてリベットとして作用する構造です。このため、板の裏側にはナットが飛び出している形になります。このナットは並目1.0なので、すでに購入したベアリングがしっかるハマるはずです。

それから薄板に9φまたは9.1φの穴をきれいに開ける必要がありますが、通常の鉄工ドリルで開けるとおむすび型にゆがみます。これはドリル刃の断面を見れば理由がわかります。なのでステップドリルか薄板用ドリルが必要になります。

ということでちょっとナッターを注文してみます。

その2に続く。

FreeCADからLibreCADに図面をエクスポートする。

FreeCADは3D CADですが、一応2D図面もTechDrawワークベンチなどを使用すれば作成することができます。
ところが現状ではどうも寸法の記入が好みじゃなかったり、この寸法のを入れたいのにできない、というような、かゆいところがたくさんあります。

そんなとき、2D CADとしてこなれているLibreCADを使って三面図や平面図を作ると、かなり楽ができます。もっともユーザインタフェースと操作方法がぜんぜん違うため、慣れるまでは戸惑いますが…。

前置きはこのくらいにして、実際の方法です。

まずFreeCADで作成したデータから2次元CADにデータを取り込む必要があります。この部分は、FreeCAD export 3D 2Dというビデオで結構解説されていました。

1. FreeCADで図面に落としたいオブジェクトを選択して、BREP形式でエクスポートします。
2. FreeCADで新規プロジェクトを作成し、エクスポートしたBREPファイルを読み込みます。
3. Draftワークベンチで投影図 (Create Shape 2D views of selected object) を3面分作ります。
4. 3Dオブジェクトを非表示にして、三面図を適切に並べ直します。
5. 三面図を選択して、DXF形式にエクスポートします。
6. LibreCADを起動して、エクスポートしたDXFファイルを読み込みます。
7. 寸法や図枠を編集します。

3のDraftワークベンチがミソです。

実際にやってみます。
まず適当な図形をPartワークベンチで作ってみます。

次にオブジェクトを選択し、BREPフォーマットでエクスポートします。

新規図面を開いてエクスポートしたBREPファイルをインポートします。あるいは単純にBREPファイルを開きます。

次に正面ビューにします。正面ビューになったら、テンキーの"1"または"Front View"を選びます。その状態でツールバーの "Auto" ボタンを押します。するとグリッドがX-Z平面になります。

"Create Shape 2D views..." のボタン（立方体の下に四角形が描かれたアイコン）をクリックします。

するとX-Y平面上に投影図が描画されます。

次にTopビューにして、ツールバーの "Auto" ボタンでグリッドをX-Y平面にします。オブジェクトを選択し、"Create Shape 2D..." ボタンを押します。オブジェクトを非表示にすると、2つの投影図が重なっています。

さらにRightビューにして同じことを繰り返します。再度トップビューにして作業プレーンをTopにし、斜めから見ると下のようになっています。

それぞれの投影図を適切に回転させて配置すれば、以下のようになります。

並べ終わったらDXFフォーマットでエクスポートします。

セーブしたDXFファイルをLibreCADで開くと、ちゃんとエクスポートできています。随時、寸法レイヤとか補助線レイヤとか図枠レイヤなどを追加して編集するか、あるいは予めレイヤを定義したテンプレートを開いてからそこにDXFファイルをインポートすればOKです。

EXEファイルからアイコンを取り出す。

事の起こりはKiCADのアップグレードでした。

KiCADがメジャーアップデートを行い、これまでの4.0.xから5.0.xになりました。内容としてはけっこう変わっているようで、特に大きいのは回路図シンボルとフットプリントのライブラリ関係。これがごっそり変わってしまうと、これまでの図面からライブラリの参照ができなくなるという問題が発生します。これが発生してしまうとけっこう問題が大きく、回路図ではシンボルの再指定が必要ですがピン番号や位置、サイズなどが変わっていると回路図自体のレイアウトを調整する必要があります。またフットプリントが変わってしまうと、これも再読込が必要となりますが、もしも原点が変わっているとせっかく配線した基板図がガチャガチャになってしまいます。

なので、データリリースするまではアップグレードを見合わせていましたが、一段落したのでアップグレード作業を行いました。

そうは言ってもKiCADでは過去のアップデートでもいろいろとライブラリ関係は仕様変更があって痛い目を見ているので、4.0.xの環境も当面は残しておきたいということもあり、Installing KiCad v4 and v5 side by sideを参考にしました。

やっていることはそんなに難しくなくて、

1. %USERPROFILE%\AppData\Roaming\kicad\kicad_common ファイルをデスクトップなどに退避コピーする
2. システム環境変数に KICAD_* という環境変数があればすべて削除する
3. インストール先を %ProgramFiles%\KiCad ではなく、%ProgramFiles%\KiCad5 にしておく
4. デスクトップに作成されたKiCadのショートカットのプロパティを cmd.exe /c "set ^"KICAD_CONFIG_HOME=C:\Users\MyUserName\Documents\kicad5\^" && start /d ^"C:\Program Files\kicad5\bin^" kicad.exe"に変更する
5. %ProgramFiles\KiCad\bin\kicad.exe のショートカット（KiCAD 4.x）を新たに作り直す

でインストール自体は終わりです。

ところで、上記の方法だと4で cmd.exe を呼び出しているため、ショートカットのアイコンが cmd.exe のものになってしまいます。そこで KiCAD5のアイコンにしようかと思ったのですが、それだと4と5の区別がつきにくい。アイコンのデザインは変わっていないからです。

ということでKiCADのアイコンをEXEファイルから取り出して、Kritaで加工しようと思い立ちました。

さてどうやってアイコンを取り出そうかと検索したところ、Windows Power ShellのモジュールでIconExport 2.0.0というのを見つけました。インストール方法はこちら。特に管理者権限などは必要なく、"-Scope CurrentUser" を引数に足せばインストールできます。

PS> Install-Module -Name IconExport -Scope CurrentUser

使い方は、

PS> Export-Icon -Path [exeファイルへのフルパス] -Directory [出力先]

です。

これで取り出したアイコンファイルを編集して、ショートカットのアイコンの変更で設定すればOK。

ボール盤台車の材料を揃える。

ジョイフル本田とモノタロウで購入したものは以下のとおりです。

品名	数量	価格
防腐レッドウッド 2x4 2440mm	1	880
加工代	2カット	100 (@50)
ユニクロ六角ナット M6	32	160 (@5)
ユニクロワッシャー M6	64	256 (@4)
ユニクロ六角ボルト M6x90	16	816 (@51)
ユニクロ六角ボルト M6x55	16	320 (@20)
ユニクロ六角ボルト M10x110	2	180 (@90)
ユニクロ六角ナット M10	2	16 (@8)
ユニクロワッシャー M10	2	12 (@6)
ナンシン 自在車 STC-50EM S-1 ストッパー付	2	478 (@239)
ナンシン 固定車 SKC-50EM	2	338 (@169)

しめて3,556円でした。その他に、6.5mmのミドル木工ドリル（@898）と10.5mmのショート木工ドリル（@698）を購入しています。
また、電動丸ノコをドイトでレンタルして500円かかっています。その他の工具類は手持ちのものを使いました。

ユニクロではなくてステンレスにするとボルトナットの値段が10倍近く跳ね上がるので、けっこうお高いものになってしまいますが、今回はユニクロにしたので思ったよりも安く上がった感じです。木材も安かったですし。

ちなみに丸ノコのレンタル費用は通常は1,000円なのですが、MAJICA会員になると半額の500円になります。会員になるのに100円かかりますがそれでもお得なので、この機会に会員になっておきました。

時間優先だったので途中経過は写真を撮っていないのですが、一応組み上がりました。組み上がったんですが…。

M6x55のボルトは長すぎました。板厚38mm、ワッシャー1枚1mm、ナット高さ5mm、車輪の支持部厚さ2mmとして合計46mmなので、せめて50mmにすべきでした。とりあえず干渉はしていないのでよいことにしておきます。

当初はキャスタの固定は木ねじにしようかとも思ったのですが、重たいものを載せるため、段差などで車輪に前後方向のショックがかかるとまずかろうと思いボルト締めにしています。板の重なり合う部分は、木工ボンドで接着しているので木ねじでも十分なのですが、ツーバイ材の表面はきれいな平面ではないためにこれもボルト締めにしています。

できあがったのでボール盤をばらして載せ替えようと思ったのですが、ヘッド部が外れないため無理でした。さすがに67kgを一人で移動させるのは危険です。
たぶんヘッド下部にある六角ボルトを外せば取り外せると思うんですが、なにしろマニュアルがNSD-13Rのものしか手に入らず、NSD-13は若干構造が古いため細かい部分が違うのです。台座の固定穴も13RはM12だけど13はM10ですし。

レッドウッドとボール盤台車。

とても幸運なことに近所にジョイフル本田があって、そこでレッドウッド材を置いていたので、9時の開店時刻すぐを狙って買いに行ってきました。10時を過ぎるとDIY人気のためか工作室の順番待ちがすごいことになってしまうので、朝一番に飛び込むのか、平日の17時以降を狙うのがいいかと思います。

今回購入したのは防腐レッドウッドの2x4で長さは2,440mm。必要な長さは650x2と400x2だったので、カットを900mmと700mmでお願いしました。1カット50円なので計100円です。カットされたものは持ち帰り、最終的な長さにするのは自分で行います。ちなみに丸鋸を持っていないので、今回はレンタルで済ませようと思っています。

材料の会計を済ませて工作室に持ち込むと、住所氏名電話番号と、どういう加工をしたいかを紙に書いてくれと言われてその通りにしました。上記の通り、900と700でカット位置を記入して渡すと、20分くらいかかるよ、とのこと。カットが終わったらカートに入れてそこに並べておくので、時間になったら取りに来て会計してくれとのことなので、その間に必要なボルトナットを買うことにしました。

無駄な待ち時間をなくすためには、

1. あらかじめ材料の選定と必要なカット長さを明確にしておく
2. 他のものは後回しにして、とにかくカットしてもらう材料を購入していち早く工作室に持ち込む
3. 工作依頼が終わってから、その他の必要なものを買う

ということですね。

今回はボール盤用の台車を作るのですが、ステンレスや黒色酸化皮膜などは錆びにくいけれど高いので、ユニクロねじにしました。使っていて錆がひどくなるようならまた考えます。

ボルト・ナットとワッシャー、ついでに6.5の木工ドリル（ミドル - 150mm程度）を購入して工作室に戻るとカットは終了していたので、会計をしておしまい。効率的です。

ちなみにうちにはボッシュの18Vバッテリーがあるので、もし工作熱が上がるようなら160mmの丸鋸を購入することも考えようかなとも思っていますが、最大100x100の角材を切ることも考えられるので、その場合には190mm以上のテーブルソーかスライドソーが欲しいかも。ちなみにスライドソー（丸鋸）は日立（現在はHiKOKI）やマキタがありますが、おすすめは日立です。というのも日立のスライド方式は1段、マキタは2段となっていて、1段のほうが精度がよく出るからです。これは機構的な問題なので、いくら丸鋸自体がよくてもどうしようもないですね。
もしも本格的に始めるなら、それに加えて集塵機も必要となるでしょうし、ちょっとペンディングです。

さて、自宅に戻ってボール盤台車の図面を仕上げます。アプリはLibreCADを使います。

今回は外注するわけでもないので、長さとドリル位置さえ正確に出せればよいため、全部実線で書いてしまいますが、とりあえず貼り付けておきます。DXFがアップロード出来ないようなのでPNGで。

キャスターはナンシンのものを購入しましたが、ナンシンのサイトにユーザ登録すればCADデータをダウンロードできるのでありがたく使わせてもらいました。

ボール盤の固定穴は板の端に近いですが、ブレ止めなどではなくて位置固定がメインなのでよしとしました。不安なようであれば2x6材などを使って幅を稼げばいいかと思います。
ちなみに台車の形はこちらを参考にさせていただきました。

明日は工作です。

WordPress on Nginx on Windows。その1

追記(2019/04/13): Windows10でNginx+MariaDB+Wordpressをインストールする。その1に書き直しました。

システムの更新に伴って、もう数ヶ月も自宅サーバのブログが動いてません。いろいろ試してうまくいかないのでどうしようかと思ってるんですが、とりあえず一時退避でこちらのブログを使っています。

なぜそんなことになったかというと、まずプラットフォームの NetBSD が 8.0 をリリースしたのでアップグレードし、さらに PHP での MySQL サポートをこれまでの mysql ドライバが非推奨になり、mysqli ドライバに切り替わったことで DB への接続が変わってしまい、また Apache も 2.4系で設定が変わったという複合的な要因があったためで。

もういっそ Nginx にしてしまおうか、それなら uWSGI も使えるし、ブログは WordPress から Mezzanine にお引越しすればいいか、と考えたのですが、うちのサーバでは Perl CGI や mailman なども動いていて、なかなかめんどくさい。

全部 Nginx でできればいいんですが、PHP に関しては FastCGI にするか、uWSGI の Emperor モードにするかも悩ましいところですし、Perl CGI に至っては「もしかしてこれは Apache に処理させて、Nginx に proxy させるのが一番なのでは…」などと思い始める始末。古い技術に引きずられてしまっています。

ただ、WordPress にはこれまで書きまくった大量のエントリがあって、実はちょくちょく参照したい。データベースの方は dump してあるんですが、そのままではテキストエディタで読み込んでも使えない（1行が長すぎるなど）のため、ローカルに MariaDB をインストールして読み込ませました。そこに HeidiSQL を使ってクエリを飛ばして検索しているんですが、どうにも使いづらい。なのでいっそ、暫定的にローカルブログにしてしまって、ブラウザからアクセスするほうがいいかと思ったのがきっかけです。

その裏では新しく Manjaro Linux を使ってサーバを置き換えようかと準備は進めているのですが…。ところで記法は Nginx なんでしょうか、nginx なんでしょうか。


閑話休題。

Apache はモジュールの管理などいろいろと無理しているところもあり、設定も複雑化してきているので「管理で楽をしたい」というならば Nginx のほうがよさそうな感じです。
そうしたことを見据え、さらには慣れておきたいということもあって今回は Nginx を動かし、その上で WordPress をサーブさせるという方向でいじってみます。
実はすでに MariaDB はインストールされているため、そのへんはここでは触れません。

Nginx のインストール

まずはNginxのインストールです。一応 Cygwin64 などは使っているのですが、そこらへんは今回あまり関係ありません。
Nginx のサイトから、ダウンロードページに飛んで、Mainline のnginx/Windows-1.15.5をダウンロードします。
これは ZIP ファイルになっていますので、ダウンロードしたら展開し、いつもどおり c:\Apps\Nginx 以下に配置します。

そうしたら何もせずにいきなり nginx.exe をクリックすると、Nginxが常駐しサービスが始まります。ポート80を開くので Windows ファイアウォールの警告が出ますが、これは OK で先に進めます。あくまでデフォルト状態なので、コンテンツは Welcome メッセージだけですが、ブラウザで http://127.0.0.1/ にアクセスすると "Welcome to nginx!" というメッセージが表示されます。

PHPのインストール

Nginx が動いたらPHPをインストールします。PHPのダウンロードページに飛ぶとWindows用のリンクがあるので、そこを開きます。そこには64/32bit、Thread Safe/Non Thread Safe という形で4つのリンクがありますが、こちらの環境は Windows 10 64bit なので 64bit の Non Thread Safe 版をダウンロードします。
Thread Safe と Non Thread Safe のどちらを選ぶべばよいかは、PHP の FAQ に書かれています。

==
What does thread safety mean when downloading PHP?
Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Thread Safety works by creating a local storage copy in each thread, so that the data won't collide with another thread.

So what do I choose? If you choose to run PHP as a CGI binary, then you won't need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP.

PHPをダウンロードする際に、thread safetyとは何を意味していますか？
thread safety は、たとえば Windows 上の Apache2 のようなマルチスレッドの Web サーバ環境で動作できるバイナリのことです。Thread Safety はそれぞれのスレッドに対してローカルなストレージコピーを作成することで、他のスレッドとデータの衝突が起きないように動作します。
それではどちらを選べばよいか？ もしも PHP を CGI バイナリとして走らせるのであれば、thread safety である必要はありません。なぜならバイナリはリクエストごとに起動されるからです。IIS5 や IIS6 のようなマルチスレッド Web サーバを使用するのなら、thread safe な PHP を使うべきです。
==

ということで、FastCGI を使う場合には一番上にあるNon Thread Safeを選べばよいでしょう。
さて、ダウンロードした PHP はこれもまた ZIP ファイルなので、展開して同じように c:\Apps\PHP に置きます。あまりルートディレクトリがごちゃごちゃするのは好きではないので。
配置したら、環境変数を設定します。



一旦システム環境変数に PHPPATH という名前で環境変数を作成し、それを PATH に参照させます。


自分の場合は、長い文字列のなかでパスのだぶりを見つけるのがとても面倒なのでこうしています。
特に「特定のパスを参照させたくないとき」にダブりがあると、期待された結果が得られないことがあるのですが、こうすることでわかりやすくしています。

パスの設定が終わったら新規でコマンドプロンプトを開き、

$php -r "phpinfo();" | grep -i thread
Thread Safety => disabled

として動作しているのを確認します。
インストールされたものを眺めてみると、 c:\Apps\PHP\ext 以下にモジュールが一通り入っていますので、iconv や mbstring、gd、exif などのインストールは必要なさそうです。また MySQL ドライバとしては、mysqli と pdo_mysql が両方含まれています。WordPress からはどちらでも使えるようなので、心に留めておきます。

FastCGIの設定

Nginx と PHP をインストールしたので、WordPress をインストールする前に FastCGI で PHP を動作させる確認をします。
参考にするのは、Nginx のサイトから PHP-FastCGI on Windows と PHP FastCGI Exampleです。それに PHP のサイトにも FastCGI Process Manager (FPM) というページがありますが、これは FPM を使用する場合なので今回は無関係です。そもそも Windows 版には php-fpm.exe は付属していません。

上記のページには、コンソールを隠した状態で起動したい場合についても書いてあります。lighttph のサイトからRunHiddenConsole.exeというヘルパーアプリをダウンロードして使えばいいとありますが、ここでは使いません。常時サービスするわけでもありませんので。

さて、FastCGI を動かすには、すでにインストールされている php-cgi.exe を引数付きで起動すればよいようです。

php-cgi.exe -b 127.0.0.1:9123

ローカルホストのポート9123にバインドする、というオプションで起動します。ポート番号は任意ですが、WikipediaのTCPやUDPにおけるポート番号の一覧などを参考に空きポートを利用するのがよいでしょう。特にこだわりはないので上記のポート番号を利用することにします。ただし、外部に開放する場合にはファイアウォールなどでポートアクセスを弾く設定も必要になりますので、下手にこだわるよりはデフォルトのまま利用したほうが、あとから見て「これなんのポートだっけ？」ということになりにくいです。

さて、コマンドプロンプトを開いて上記のコマンドを実行すると、コンソールには何も表示されずにプログラムは実行状態になります。これはリクエストを待っている状態です。

次に Nginx の設定を行います。

まずはドキュメントルートを作成します。ここでは c:\srv\www としておきます。これは Linux Foundation の Filesystem Hierarchy Standard (FHS) に定義されているディレクトリ構造によります。詳細は 3.17. /srv : Data for services provided by this system を参照。ただし Linux Distribution によっては /var/www などとしているものもあります。このへんについてはコンセンサスが取れていないようですが、ここでは直感的に「サーブされるデータ」ということで /srv にしておきます。

ドキュメントルートが決まったら、これをnginx.conf に反映します。

上記ページには、

root c:/www;

location ~ \.php$ {
    fastcgi_pass   127.0.0.1:9123;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include        fastcgi_params;
}

となっていますが、c:\Apps\Nginx\conf\nginx.conf を以下のように修正します。

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9123
#
location ~ \.php$ {
    root           c:/srv/www;
    fastcgi_pass   127.0.0.1:9123;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $fastcgi_script_name;
    include        fastcgi_params;
    include        fastcgi.conf;
}

念のため、何かあれば参照できるようにもともとの nginx.conf は nginx.conf.orig とでも名前を変えて保存してから、編集します。実際には nginx.con の63行目から同様の記述があるので、そこのコメントを外していじればOKです。

ここでひとつ注意しなくてはならないのは、コンソール（コマンドプロンプト）から nginx.exe を起動すると、それを終了することが困難な点です。これはバッチファイルでも同じ。
すでに nginx を起動しているコンソールがあるとして、別のコンソールから nginx -s stop などとしても

nginx: [alert] could not open error log file: CreateFile() "logs/error.log" failed (3: The system cannot find the path specified)
2018/10/29 13:04:11 [emerg] 1588#5708: CreateFile() "C:\Apps\Nginx/conf/nginx.conf" failed (3: The system cannot find the path specified)

などとでてきて停止も終了もできません。もちろん nginx.conf を更新してから reload させようとしても同じようです。そこでコンソールを閉じても、実はバックグラウンドジョブとして nginx が生き残ってしまうので、nginx.conf を修正して再起動したつもりでもちゃんと反映されない、ということになります。

コンソールから起動した nginx.exe を終了させるには、どうやらタスクマネージャーから nginx.exe を探して一つづつ「タスクの終了」をするか、別のコンソールから taskkill /f /im nginx.exe するしかないようです。

一方、エクスプローラから nginx.exe を直接起動したり、ショートカットを作ってそこから起動した場合にはシグナルを受け取って正常に終了するようです。

php-cgi と nginx を起動したら、PHP のテストファイルを用意します。以下の1行のみのファイルを index.php として c:\srv\www に保存します。

<?php phpinfo(); ?>

そしてブラウザから http://127.0.0.1/index.php にアクセスし、エラーとか応答なしとか "No input file specified." などという文字ではなく、下のようなページが表示されればOKです。