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帯で規格化されているようですね。