8th way to explore the world

軟骨伝導ヘッドホン

noreply@blogger.com (EMO) — Sat, 25 Jan 2025 08:28:00 +0000

audio-technicaの軟骨伝導ヘッドホンの新モデルATH-CC500BT2が出ていたので、チェック。

性能面は旧モデルATH-CC500BTからよくなっているだろうから心配してなくて、自分の関心はデザインとフィット感。

旧モデル（上）はShokzなどの既存の骨伝導ヘッドホンとはあえて違う形状を目指した感があったが、新モデル（下）は既存製品に近い形状になっている。

旧モデルはスピーカー部（振動ドライバー）が妙に丸っこく膨らんだ形で、謎のエングレーブが入っていたりして、ここはあまり好きではなかったが、新モデルは小さくすっきりした形になっている。

旧モデルではスピーカー部にボタンとマイク穴（左側）があって、開発陣は、ボタンはここに置いた方が直感的で、マイク穴も口に近い方がよいと考えたのだろうけど、これらをつるに移動させたのは、ボタンは音量ボタンと同じ位置の方がむしろ操作しやすく（オーバーヘッド型ヘッドホンではそうしている）、マイク穴はつるでも声は十分拾えると考えたのだろうと思う（想像）。

振動ドライバーが耳珠に接触する面積は、旧モデルは形状の関係で意外と小さく、新モデルの方が大きいので、位置調整できる幅は大きい。

フィット感については、自分の頭へのフィット感は確実によくなっている。総じて順当な進化なので、旧モデルもまだ十分使えるので惜しくはあるが、買換えに値すると思う。

インストールされたアプリの情報取得

noreply@blogger.com (EMO) — Thu, 13 Apr 2023 21:43:00 +0000

別に新しくも何ともないですが、パッケージされたアプリをインストールした後、登録された情報はPowerShellで簡単に確認できます。

PowerShellコンソールから以下です。

Get-AppxPackage

これをファイルに記録するには、デスクトップにpackages.txtというファイル名で保存するとして、こうです。

Get-AppxPackage > $env:USERPROFILE/Desktop/packages.txt

ちなみに、UWPをVisual StudioからLocal Machineで実行したときに自動インストールされたものは、IsDevelopmentModeがTrueになるようです。

パッケージされたアプリのファイルの保存場所

noreply@blogger.com (EMO) — Tue, 29 Nov 2022 15:57:00 +0000

AppDataフォルダーへのファイル作成について、発見があったのでメモしておきます。

1. 基本

Microsoftストア用にパッケージされたデスクトップアプリの場合、設定情報等の保存場所としては基本的に以下の3通りがあります。

WinRTのApplicationData.LocalSettings
WinRTのApplicationData.LocalFolderに作成したファイル
AppDataフォルダー（に作成したフォルダー）に作成したファイル

1番目と2番目はUWP用のものですが、パッケージされたアプリであればこれらを使えます。3番目は、使い方は普通のアプリと同じですが、実際のAppDataフォルダーではなく、OSが管理する別の場所に自動的にリダイレクトされるところが違います。

これらのファイルはアプリのアンインストール時に自動的に削除されます。つまり、アプリの実行ファイルのみならず、その作成する情報・ファイルもOSがまとめて管理することで、ゴミとなるファイルを残さずきれいに削除できるようにしているわけです。

Understanding how packaged desktop apps run on Windows

ちなみに、AppDataフォルダー以外にもアクセス権に応じてファイルは作成できますが、あえてやることでもなし。

2. 発見

ここまではDesktop Bridgeの基本ですが、3番目について、ふとしたことから例外があるのに気づきました。

すなわち、アプリをインストールした後、最初にAppDataフォルダーにファイルを作成しようとした際に、

AppDataフォルダーに指定のフォルダーが存在しない場合、自動的にリダイレクト先の場所が作成され、以後のアクセスはその場所になる。実際のAppDataフォルダーには何も作成されない。これは公式情報どおり。
AddDataフォルダーに指定と同名のフォルダーが既に存在する場合、そのフォルダーにファイルが作成される。このファイルはアプリをアンインストールしても削除されない。

この2通りのどちらになるかは、最初にアクセスしたときに決まるようです。一旦、1.になった後は、AppDataフォルダーに同名のフォルダーを作成しても、ファイルはそこに作成されません。

開発環境では、パッケージされた状態で実行するときもあれば、されていない状態で実行するときもあり、2.のようなケースがあるのには何となく気づいていましたが、改めて確認したところ、こういうことだったと。

これがどういう意味を持つかというと、例えば、ユーザーごとのTempフォルダーであるAppData\Local\Tempに作成するファイルはリダイレクトされないし、作成された後はアプリをアンインストールしても自動的に削除されないということになります。

他人のことはあまり言えませんが、説明が足らないと思います。

Razer Pro Click Mini

noreply@blogger.com (EMO) — Mon, 06 Jun 2022 03:29:00 +0000

ゲーミングマウスの性能で高速スクロール可能なモバイルマウスがほしいという願望がずっとあって、サブに使っていたMX AnyWhere 2Sの買い替えを機に、Razer Pro Click Miniを買ってきた。

エクステリアデザインはエクセレント。Logicoolのモバイルマウスの最上位ラインはちょこちょこデザインを変えてきているが、「こういうのでいいんだよ」をとてもきれいにまとめた感じ。一応チェックした大きい方のRazer Pro Clickは縁にクロームのラインをあしらっているが、別にそういうのは要らない。

製品としては明らかにMX AnyWhere 3の対抗馬で、バッテリーが固定内蔵でないのが違うが、重量は単3一本の状態で実測でほぼ同じ（4g軽い）なので、使用上は大きな違いはない。単4一本にすればさらに軽くできる。

Pro Click Mini: 92g（単3一本）
Pro Click Mini: 81g（単4一本アダプター込み）
MX AnyWhere 3: 96g

ちなみに、上面蓋をどう固定しているのかと思ったら、本体の最後部にマグネットが仕込んであって、それで蓋のネジを引き付ける仕組みになっていた。したがって、爪が折れたりする心配とは無縁だが、机から落としたりすると簡単に外れて飛んでいくので、それはそれで注意が必要かも。

追随性とかは自分には正直差が分からないので、確認点はクリック音とホイールの回転。

クリック音

Pro Click Miniはクリック音が小さいのを売りの一つにしているが、確かに小さい。擬音的には、「カチッ」というより、小さく「ポクッ」という感じで、音が小さくかつ低音なので響かない。まあこれは、むしろLogicoolがMX AnyWhereのラインで重視していないのが謎な点ではある。

ホイール

まずフリーホイールとの切り替えはホイール手前のシーソースイッチで行うが、これが少し硬い。ただ、自分は常にフリーホイールで使うので（TrackPointで鍛えられた人間なので、ノッチに頼らなくても支障はない）、むしろ勝手に変わらなくてよい。

ホイールにはラバーに四角錐が5個並んだ滑り止めが施されている。

肝心のホイールの回転については、MX AnyWhere 3の極まったホイール（無音・無抵抗で、ブレもなく、とてもよく回る）に比べると、回転音がしてかすかにブレがある分、少し劣ると言わざるを得ない。シフトスイッチのあるMX AnyWhere 2Sよりも劣るので、この点はLogicoolに一日の長があるのだろうと思う。

ただ、これは極まったMX Anywhere 3と比べての話で、実用上の問題はない。

まとめ

結論としては、クリック音の小ささではPro Click Miniに、ホイールの回転ではMX AnyWhere 3に軍配が上がる。どちらも使い倒すけど。

.NET 5でのアプリの更新

noreply@blogger.com (EMO) — Fri, 03 Jun 2022 14:26:00 +0000

Microsoftストアで公開したアプリはストアのAPIを使って更新できますが、.NET 5以降は変わった点があるので、メモしておきます。

Microsoftストアからのアプリの更新

更新の際に出るダイアログのために、このオーナーとなるWindowを先に登録する必要がありますが、これは.NET 5より以前は以下のようなものでした。見てのとおり、COMのIInitializeWithWindowを定義しておいて、StoreContextのインスタンスをこれにキャストするものですが、.NET 5以降はInvalidCastExceptionが出て実行できなくなります。

このための修正としては、usingにWinRTを加えた上でAsでIInitializeWithWindowキャストする。もしくは、WinRT.Interop.InitializeWithWindow.Initializeを使う。これが公式に出ている方法で、StoreContextをキャストする必要がなく、したがってCOMの定義も要らなくなるので、やるならこちらだと思います。

Using the StoreContext class with the Desktop Bridge

これを含めた更新のためのヘルパークラスの全体は以下のようになります。

ソリッドなL型ミニプラグ

noreply@blogger.com (EMO) — Sat, 27 Nov 2021 14:50:00 +0000

ヘッドホンのミニプラグをオヤイデ電気のP-3.5 SRL＋スプリングに交換したので、記録として。

有線ヘッドホンは、定番のオーソドックスなものにしておこうという理由でSonyのMDR-CD900STを随分前に買って、これは実際に交換部品の入手のしやすさで正解だったのだけど、元のプラグは太い標準プラグなのでミニプラグへの改造が前提で、これを何度か交換してきた。

PCやタブレットのオーディオジャックは側面にあるので、L型のプラグの方が取り回しがよさそうということで、オヤイデのP-3.5 SRLを買ってみたものの、ハンダ付けの難易度が高そうなのと、スプリングが付いておらず、ケーブルの穴径が6mmで穴が余るので（後に穴径が4mmのものが出た）、使わずじまいになっていた。

で、前回の交換時にハンダ付けに手間取っている間に熱で樹脂部分が傷んでいたのか、プラグが壊れたので、P-3.5 SRLを出して眺めていて、ふと思いついて前のプラグに付いていたスプリングをぐいぐい押し込んでみたら、スプリングの外径がぴったり合うことが分かったので、これでやってみるかと作業開始。

黒のアースを付ける位置に迷ったが、フラックスを塗布しておくことでハンダ付けは問題なく終了。

と思ったら、かしめるためにケーブルをねじる途中で黒が切れたので付け直してから固定。ちなみに、現行製品とは端子の穴が違う。

よく見ればスプリングとはメッキの光沢が違うものの、コンパクトかつソリッドな外見で、断線防止のスプリングもあるという、個人的に理想のL型ミニプラグができた。

Surface Pro 8にWindows 10をインストール

noreply@blogger.com (EMO) — Sun, 14 Nov 2021 09:31:00 +0000

Surface Pro 8はSurface Proシリーズのユーザーが待ち望んでいた新機種ですが、発売タイミングの関係か、一般向けはWindows 11プリインストール機のみの販売となっています。

純粋に使うだけなら別にWindows 11でもいいですが、検証などを考えるとWindows 10の環境も当面必要なので、Windows 10をクリーンインストールしてみたところ、3点引っ掛かったことがあったので、メモしておきます。

1. インストール用USBメモリ

これはSurface Pro 8に特有の点ではないですが、Surface Pro 8のUSBコネクタはUSB-C（Thunderbolt 4）だけなので、インストール用USBメモリは、USB-Cのものを使うか、USB-CとUSB-Aの変換コネクタをかませる必要があります。

ここで、容量が大きめ（32GB＝32768MB超）のUSBメモリを使おうとすると、フォーマットでファイルシステムが自動的にexFATになりますが、USBメモリからブートするにはFAT32である必要があるので、何らかの方法でFAT32にする必要があります。

ただ、この点はMicrosoftのメディア作成ツールでUSBメモリの作成までやってしまえば、自動的に32GBでFAT32のパーティションが作られるので、たいした問題ではありません。

2. 入力デバイス

インストール用USBメモリからブートすると、最初に言語や地域を設定する画面が出ますが、ここで本体のタッチスクリーンもSignatureキーボードも全く反応せず、何も操作できないので詰みます。

この原因が分からず、しばらく試行錯誤したのですが、ふと外付けUSBキーボードを繋いでみたら動きました。

つまり、タッチスクリーンにせよ、Signatureキーボードにせよ、これらのためのどこかのデバイスがインストーラーに含まれたインボックスドライバーでは動かないらしいというオチでした。これはOSのインストール後もWindows Updateをかけて各種ドライバーを更新するまで解決されないので、そういうことなのでしょう。

正攻法で行くならば、Surface Pro 8のドライバーパッケージ（後述）から該当するドライバーを探し出し、予めインストーラーに組み込んでおく方法で解決できるはずですが、USBキーボードを繋いだ方が百倍速いということで。

なお、使用したインストーラーは21H1のもので、Windows 11のインストーラーでも同じでしたが、いずれ修正されるかも。

3. 内蔵カメラ

OSのインストール後にWindows Updateをかければ、ほとんどのデバイスは使用可能になりますが、内蔵カメラだけは使えません。カメラが使えないということはWindows Helloの顔認証も使えないということで、実用上見過ごせない問題です。

デバイスマネージャーをWindows 11と見比べると、Windows 11では「カメラ」に存在する「Intel(R) TGL AVStream Camera」が存在せず、代わりに「ほかのデバイス」に「ISP Camera Device」があるので、これがそれらしいと目星はつきましたが、Windows Updateではドライバーが入りません。

しばらく探したところ、MicrosoftがSurface Pro 8のWindows 11用のドライバーパッケージを公開していました。

Surface Pro 8 Drivers and Firmware

この中のWindows 10用（SurfacePro8_Win10_19042で始まるもの）をインストールし、展開された「SurfaceUpdate」フォルダーの中から「Cameras」フォルダーを指定して、「ISP Camera Device」のドライバーの更新をかけたところ、「Intel(R) TGL AVStream Camera」が出現し、カメラが使えるようになりました。これでWindows Helloの顔認証も問題なし。

以上で、とりあえずのところ、Windows 10の動作に支障は出ていません。

[追記]
11/19にWindows 10用のドライバーパッケージが追加されたので、Windows 11に一旦インストールする工程は不要になりました。

4. おまけ

今回のSurface Pro 8はi7のモデルを買いましたが、季節柄か普段使いではファンはほとんど回らないので静かです。

ストレージは512GBですが、ベンダーは予想外のKIOXIA。

型番のKBG40ZNSで検索してみると、BG4というシリーズのSSDのようです。ホワイトペーパーによると、CrystalDiskMark 6.0による計測でシーケンシャルリードが最大2,336MB/s、シーケンシャルライトが最大1,815MB/sということなので、以下のCrystalDiskMark 8.0の結果は大体こんなものかと思います。

SignatureキーボードはUS版をAmazon USから購入。色はSurface Pro 7で使ってきたプラチナという名のグレイの使用感が今一だったのでブラックにしましたが、地味だったかも。

Winget 1.1

noreply@blogger.com (EMO) — Fri, 08 Oct 2021 06:55:00 +0000

CUIからソフトウェアパッケージのインストールができるWindows Package Manager、別名WingetのVer 1.1がリリースされています。

Windows Package Manager 1.1

Wingetは活発に開発が進められていますが、今回の大きな変化としてMicrosoftストアのアプリにもアクセスできるようになっています。これがどういうことかというと、従来はアプリをWingetでインストールできるようにするには、Wingetのレポジトリに登録する作業が必要だったのですが、Microsoftストアにあるアプリはこれが不要になり、そのままでWingetから見えるようになりました。

したがって、Wingetが使える環境であれば、例えばMonitorianをインストールするのに、コマンドプロンプトから以下を実行するだけでできてしまいます。

winget install Monitorian

超簡単！便利！楽！

まあ実用的に使うには、どうオプションを付けるか考えて詰める必要はありますが。

既存のChocolateyもありますが、追加的な手間がかからないというのは大きいです。

Microsoftストアからのアプリの更新

noreply@blogger.com (EMO) — Wed, 04 Aug 2021 03:35:00 +0000

Microsoftストアで公開したアプリは、Desktop Bridgeの場合も含めて、新しいバージョンが公開されているときは「Microsoft Store」アプリでそのアプリのページを開くと自動的に更新がかかります。ただ、これは往々にしてエラーになり、一旦アンインストールしての再インストールを強いられたりします。

一方、ストアのAPIには、アプリからアプリ自身の更新ができるAPIが用意されています。

Download and install package updates from the Store

このAPIはてっきりUWP用かと思っていたのですが、Desktop Bridgeでも使えるようなので、試してみました。

上のページにあるサンプルを必須部分だけにして、Desktop Bridge用の処理を加えると以下のようになります。

見てのとおり、

StoreContext.GetAppAndOptionalStorePackageUpdatesAsyncメソッドで新しいバージョンのあるパッケージ情報（StorePackageUpdate）を取得して、この有無をチェックする
この情報を使ってStoreContext.RequestDownloadAndInstallStorePackageUpdatesAsyncメソッドを実行する

これだけ見ると簡単です。が、テストしてみると全然ダメでした。

1.は、常にパッケージ情報が1つ返ってくるが、このパッケージのバージョン（StorePackageUpdate.Package.Id.Version）は、新しいパッケージのバージョンではなく、現在実行中のパッケージのバージョンを示すので、新しいパッケージがあるかは判別できない。

2.は、このパッケージ情報を使って実行しても現在のパッケージが再インストールされるだけのようで、更新にならない。

これは使い物にならないかなと思いつつ、数少ない先例を見てみると、少し気になることが。

この下の方で、Microsoftの人がどの環境（テスト用か、本番用か）で実行したか聞いているので、環境によって動作が違うのかも。と、自分もローカルでWindows Application Packaging Projectからインストールした場合と、ストアでPackage flight（特定ユーザーへの限定公開＝テスト用）として公開した場合で試しただけだったので、この際、ストアでSubmission（一般ユーザーへの公開＝本番用）として公開してみました（これを実行する古いパッケージと、新しいパッケージの両方）。

その結果、この状態であれば期待どおりに更新に使えることが分かりました。

1.は、新しいパッケージがないときはパッケージ情報が返ってこないので、その有無を捉えればよい。すなわち、以下のように、上のメソッドの前半だけで判別可能。

2.は、このパッケージ情報を使って実行すると新しいパッケージがインストールされる。

ということで、Desktop Bridgeでも使えることが確認できました。このAPIを利用すればアプリに手動/自動での更新機能を付けられるので便利、なのですが、デバッグを本番環境でやらなければならない、そのために修正の度にパッケージをSubmissonとして公開しなければならないのは、時間的に勘弁してほしいとこです。

タフな2.5インチドライブ用ケース

noreply@blogger.com (EMO) — Sat, 29 May 2021 15:25:00 +0000

2.5インチドライブ用の外付けケースとして最もタフな部類に入るSilverStoneのSST-MMS01Bを使っていましたが、StarTech.comのS251BRU31C3に買い替えたので、記録として。

この2つ、ベンダーは違いますが、コントローラー基板以外の筐体は見たとおり全く同じなので、ODM元は同じなのでしょう。

インターフェイスとコネクタは以下のとおり。

SST-MMS01B : USB 3.0 : Micro-B 3.0
S251BRU31C3 : USB 3.1 : USB-C

Micro-B 3.0はとにかく華奢で、SST-MMS01Bでもいかにもタフな筐体に見合っていない感がありましたが、どうもコネクタが歪んでしまったようで、わざと傾けて力をかけないと認識されなくなったので、引退となりました。その点、S251BRU31C3のUSB-Cはコネクタがカチリと固定されて安定感があります。

筐体の中はどんなものかというと、ドライブはコネクタ以外の全方向がゴム素材で支えられる構造になっていて、縁には防水のパッキンがあります。

蓋は六角ネジで固定するようになっています。外側のゴムジャケットも合わせて厚みは30mmとなるので、ドライブが9.5mm厚として上下に10mmの緩衝スペースがある計算になります。見えませんが、ネジ穴部分の内側にワッシャー型のパッキンがあり、ネジ穴からの防水になっています。

コネクタにはパッキン付きの蓋があります。コネクタの貫通部はシールされているようには見えないので、蓋は閉めておかないと防水性は発揮されないかと。

一応性能確認のため、古いものですがSanDiskのExtreme Proを繋いでMBP2019からAmorphousDiskMarkで計測した結果。コントローラーはasmediaのASM235CMでした。

性能的には十分かと思います。

ということで、データを物理的要因から保護するケースとして現状不満点はないです。なお、難点というほどではないですが、アクセスランプはなく、HDDでも動作音はほとんど漏れてこないので、外からは動作状況が分からないのが注意点ではあります。

Hello Switcherのサービス化

noreply@blogger.com (EMO) — Tue, 04 May 2021 12:32:00 +0000

ノートやタブレットPCでWindows Hello対応の内蔵カメラがある場合、Windows Hello対応のWebカメラを接続しても、Windows Helloに使われるカメラを切り換えられない問題は、Microsoftでも認識されているようです。

Can I use an external camera when my laptop is closed or docked?

最近ようやくというか、周辺機器メーカーから普及帯のWindows Hello対応Webカメラが出ましたし（エレコムのUCAM-CF20FBBK）、既にDellやLenovoからWindows Hello対応カメラ付きのモニターも出ています。中でもMicrosoft Teams専用機能を謳ったC2422HEについて、Dellのサポートに問い合わせてみたところ、やはりPC本体にWindows Hello対応カメラがある場合はモニターのカメラは使えないとの回答でした。この問題にぶち当たるケースが増えるにつれ、Microsoftでもいつまでも放置はされないかもと想像しています。

ともあれ、この問題を解決するためのHello Switcherですが、これまでの実績上、切換え機能自体には問題なさそうです。

emoacht/HelloSwitcher

一方で、ログイン後という起動タイミングに起因する問題は如何ともしがたく、未解決の問題として残っていました。すなわち、電源オフの間やサスペンド中にUSBカメラの着脱があった場合、その後のログイン前にカメラの切換えは当然できません。

試しにタスクスケジューラでの開始タイミングをスタートアップ時に変えてみましたが（この状態だとUIを出せないので、実用的ではない）、ログイン前にカメラの切換えが間に合う場合もあれば合わない場合もあり、解決策にはならず。

よって、Windowsサービスの実行ファイルも作成し、通常のアプリと併用する（アプリの実行中はサービスはPausedにしておく）方針に変えました。

この結果、切換えが間に合わなくなる場面はほぼなくなりました。ということで、ようやくアプリとして所期の要求を満たすようになりました、パチパチ。

実際、サービスとして動かしている限り、表に出ることもなく自動的に切り換えるので、OSの標準機能と変わりません。これで、この問題は実質的には解決かなと。

Windowsサービスでデバイスイベントを捕捉する

noreply@blogger.com (EMO) — Mon, 03 May 2021 05:57:00 +0000

実行ファイルをWindowsサービスとして動かすために.NETではSystem.ServiceProcess名前空間にServiceContollerとServiceBaseクラスが用意されていて、これらに則れば比較的容易にサービスを実装できますが、このServiceBaseの派生クラスからデバイスイベント（USBデバイスの着脱）を捕捉するにはどうすればいいか、鉄板的なものが見当たらなかったので、メモしておきます。

1. 基本

Win32的には、Windowsサービスは大体以下のような仕組みになっているようです。

まずサービス名を指定してCreateService関数でサービスを生成する。
このサービス名とコールバック関数を指定してRegisterServiceCtrlHandler関数を実行すると、サービス自体の管理用（開始、停止等）のコントロールコードがこのコールバック関数に流れてくるようになる。また、この関数の実行時にサービスステータスハンドルが返ってくるので、これをサービスステータスの管理等に利用する。
または、このサービス名とコールバック関数を指定してRegisterServiceCtrlHandlerEx関数を実行すると、２のコントロールコードに加えて、デバイスイベントを含めたシステムイベントのコントロールコードも流れてくるようになる（デバイスイベントの場合は、さらにサービスステータスハンドルを指定してイベントへの登録が必要。この部分はWindowを持つアプリでWindowメッセージを処理するのと基本同じ）。具体的なイベントについては、このコールバック関数（LPHANDLER_FUNCTION_EX）を参照。

ServiceBaseはこの2と、3のシステムイベントについては電源イベント（SERVICE_CONTROL_POWEREVENT）とセッションイベント（SERVICE_CONTROL_SESSIONCHANGE）まで実装していますが、デバイスイベント（SERVICE_CONTROL_DEVICEEVENT）は実装していません。というか、ソースを見ると、実装しかけたまま放置されたようで、これも実装してあれば手間が省けたのですが。

2. 実装

デバイスイベントの捕捉については、ざっと探して以下の先例がありました。

Capturing Device Events in a C# Windows Service

このコードをダウンロードして見ると、ServiceBaseの派生クラス上で上記の3を行い、イベントを独自のコールバック関数で捕捉するようにしています。つまり、ServiceBase内と二重にRegisterServiceCtrlHandlerEx関数を実行しているわけですが、こうするとServiceBase内のコールバック関数へのポインターが上書きされるようで、ServiceBase内のサービスステータス管理用の処理が実行されなくなります。このため、独自のコールバック関数の方でSERVICE_CONTROL_STOPを捕捉してServiceBase.Stopメソッドを呼んでいます。

とりあえず確認したところ、デバイスイベントの捕捉は問題なくできましたが、致命的な問題が。サスペンド時（Windows 10では、標準では「シャットダウン」がサスペンドになる）にAccessViolationExceptionが発生します。これは少し確認したところ、RegisterServiceCtrlHandlerEx関数を実行しただけで起こり、たぶんアンマネージドなハンドル絡みだと思うので、ほぼ対処不能。

ではどうするかというと、既にServiceBase内にコールバックの仕組みはあるので、これを利用できないかとソースを改めて見ると、コールバック関数に来たコントロールコードは途中で捕捉されなければ最終的にServiceBase.OnCustomCommandメソッドに流れてくるので、これを捕捉すればよいと発見（LPHANDLER_FUNCTION_EXにおけるdwControl ＝ ServiceBase.OnCustomCommandにおけるcommand）。カスタムコマンドは128から255までという決まりがあり、SERVICE_CONTROL_DEVICEEVENTは11なので、この範囲に入りませんが、わざわざフィルターしているわけでもないので。

ということで、これなら簡単に実装できます。デバイスイベントへの登録はWindowメッセージの場合とDEVICE_NOTIFY_SERVICE_HANDLE以外は同じ。
なお、OnStartでRegisterの前にUnregisterしているのは、OnStartの後に必ずOnStopが来るとは限らないため。

惜しむらくは、一緒に来るdwEventType（WM_DEVICECHANGEにおけるwParamと同じ）とlpEventData（同じくlParamと同じ）は流れてこないので、デバイスイベントが起きたことしか分からないことですが、イベントがあったことが分かればやりようはあるので。

このサンプルのレポジトリは以下。

emoacht/DeviceDetect

以上で用には足りますが、ServiceBaseクラスは.NETでサービスを使うには必須の基底クラスなので、もう少し拡張にオープンにしてほしかったというのが率直な印象でした。

ストライプ付きプログレスバー

noreply@blogger.com (EMO) — Sat, 10 Apr 2021 14:08:00 +0000

プログレスバーの最近の流行りは、コンテンツを邪魔しないように細くして、存在感を主張しないものだと思いますが、控えめにアクセントを付ける方法として、ストライプを付けるものがあります。それで、進行中はストライプをアニメーションさせると。

WPFというかXAMLのアニメーションはその辺柔軟なので、それほど難しくはないです。

ポイントとしては、連続して描画するタイプの要素をアニメーションさせるときは、その開始位置の値を変えていくようにすれば、比較的簡単にできます。上の例ではDrawingBrushをTileMode="Tile"を指定して敷き詰め、位置をViewportで決めていますが、このXの値を変えてアニメーションさせています。

ここでもう一つポイントとして、アニメーションにはプリミティブな値を変えるDoubleAnimationやColorAnimationをよく使いますが、Viewportの型はRectなので、この中のXはDoubleAnimationでは対象に指定できません。こういう場合は、複合的な値であるRectを変えるRectAnimationが用意されているので、これを使えばいいわけです。

同じようにThickness（Marginの型）を変えるThicknessAnimation、Pointを変えるPointAnimation、Sizeを変えるSizeAnimationもあるので、幾何学的に変化させるアニメーションは大体カバーできます。これら以外にも、AnimationTimelineの派生クラスを見ると、予め用意されているAnimationをチェックできます。

emoacht/WpfControlCollection

マルチタッチによるクリックの判別

noreply@blogger.com (EMO) — Thu, 11 Feb 2021 05:43:00 +0000

WPF上のタッチ操作でシングルタッチによるものか、マルチタッチによる（指を複数使う）ものかは、Manipulation系のイベントであれば直接判別できるようになっていますが、移動を伴わないTouch系のイベントのときは直接分かるものがないので、どうするか考えてみた話です。

そんなに難しいことでもなく、Touch系のイベントで来るTouchEventArgsのTouchDeviceがイベントを起こした個々のデバイス（指）を示すので、このIdを記録して、これが一連のイベントが終わるまでに一つしか来ていなければシングルタッチ、複数来ていればマルチタッチと判別できます。

以下のButtonの例では、PreviewTouchDownイベントごとにTouchDeviceのIdをHashSetに記録していき、Clickイベントのときに複数来ているか判別した後で、HashSetを初期化しています。なお、タッチ操作の終わりに常にClickイベントが来るわけではないので、PreviewTouchUpイベントを引っ掛けた上で、これはClickイベントより先に来るので、1秒の猶予をおいてから初期化するようにしています。
なお、一つのTouchDeviceがPreviewTouchDownで何回も来ることはないと割り切れば、単なるカウンターでも十分な気はします。

より実用的に、ClickイベントからBehaviorのCallMethodActionを実行するようにしている場合、そのIsEnabled依存関係プロパティとbindingを張ってもいいですが、そのために妙にコードが増えるのもうまくないので、CallMethodActionの分も含めてBehaviorにまとめたのが以下。
サンプル全体は以下。

emoacht/WpfMultiTouch

以上でシングルタッチかマルチタッチかに応じて実行するメソッドを切り替えられるようになりましたが、実際に試してみると、2つの指を合わせて、それぞれ認識されるまでタッチしてから離す（完全に同時にタッチする必要はない）操作は慣れが必要で、タッチデバイスにもよるでしょうが、この操作の実用性自体が少し微妙なことに気づきました。

階層的なロケール

noreply@blogger.com (EMO) — Sun, 31 Jan 2021 05:52:00 +0000

.NETアプリではリソースファイル（.resx）をロケールごとに用意しておけば、実行時にユーザーの表示言語に合ったリソースが自動的に選択されます。ロケールは基本的に[言語名]-[地域名]の構成ですが、中国語だけはこれが簡体字と繁体字のために階層的になっているので、確認してみました。

各ロケールのCultureInfoのParentプロパティを辿るとInvariantCultureに辿り着きますが、その一つ前までをまとめてMarkdownの表を生成するコードが以下のとおり。
これを.NET Framework 4.8の上で実行した結果。
自動選択では表示言語と同じリソースがあればそれが、なければ上に辿って存在するリソースが選択されるはずなので、簡体字の場合、表示言語がzh-CN（中国本土）のときはzh-CNのリソースがあればそれが、なければ（zh-CHSは古いものなのでスルーするとして）zh-Hansのリソースがあればそれが選択されることになります。ここで、簡体字なのは中国本土だけだろうと思っていたら、実はシンガポールも簡体字を使っていて、リソースをzh-CNで作成すると表示言語がzh-SGのときには選択されません。

同じように、繁体字の場合、表示言語がzh-TW（台湾）のときはzh-TWのリソースがあればそれが、なければ（zh-CHTはスルーするとして）zh-Hantが存在すればそれが選択されますが、リソースをzh-TWで作成すると香港かマカオで表示言語に繁体字を使っているときには選択されないことになります。

したがって、簡体字のリソースはzh-Hansで、簡体字のリソースはzh-Hantで作成するのが正解で、もし分ける必要が出てきた場合に、その下のロケールで該当部分を上書きすればいいわけです。

念のため、.NET 5.0の上で実行した結果。
これも古いzh-CHSとzh-CHTが消えた以外は同じですが、説明に簡体字か繁体字か明記していないのが不親切。

以上、中国語のロケールはそれぞれzh-Hansかzh-Hantにしておけばよい、という確認まで。

Dellモニタースタンドの限界突破（下方向）

noreply@blogger.com (EMO) — Thu, 28 Jan 2021 00:17:00 +0000

Dell U2415をサブモニターとして使っていますが、設置場所の関係でやや高い位置に置かざるを得ず、モニタースタンドの下限一杯にしてもモニターの位置が視線の高さに対して高くなるという問題がありました。

こういう場合の解決策としてモニターアームの使用が考えられますが、あれはあれで設置に手がかかり、かつ位置調整も全く融通無碍にできるわけではありません。そこでモニタースタンドの改造で何とかできないかと検討。

スタンドのモニターとの接続部のプレートを一旦取り外し、カバーを外して取り付け直したところ。

この左右の端の中央の高さにある横長の穴は、カバーのダボがはまっていた部分で、組み立て時の位置決め用と推測しますが、もしかしてこれにVESAマウントのネジを通せないかと思い付き、穴の間の距離を測ったところ、ネジの中心になる位置の間で101mm。VESAマウントは100mmなので、微妙に合いません。

穴をそれぞれ内側に削る手もなくはないですが、このスチールのプレートを手作業で加工するのは率直に言って苦行。どうしたものかと手持ちの金具を漁っていたら、ピカーンと。

モニターのVESAマウントのネジ穴に黒いクランク型の金具を少し傾けて取り付けることで、ネジ位置をスタンドのプレートの穴に合わせることができると。いずれにせよスペーサーが必要だったので、一石二鳥。何かの用に使おうと買ったまま長らく死蔵していたものですが、まさか役に立つ日が来ようとは、「こんなこともあろうかと」が本当にあるとは、自分でも少々びっくり。

とりあえずスタンドに取り付けてみたところ。横2点だけの固定なので縦の揺れはあるものの、厚みのあるスチールの金具なので、それ自体の強度には問題なさそう。

まあ大丈夫そうなので、根本のカバーを戻し、プレートの下型の爪の部分にゴムを挟んで揺れ止めにして、一応の完成。

この結果、モニターの位置を大きく4cm弱下げることに成功（スタンドの台座との隙間は8mm）。このスタンドのプレートの穴はU2720QMのスタンドにもあったので、Dellのモニターで割と汎用的に使えるテクではないかと思います。あくまで緊急避難的なものですが。

アプリ実行エイリアス

noreply@blogger.com (EMO) — Thu, 31 Dec 2020 09:26:00 +0000

Microsoftストアにアプリを出すときに、app package manifestで「アプリ実行エイリアス」というものを指定できます。この効能はストアからインストールしたアプリ（デスクトップアプリを含む）をコマンドプロンプトからファイルパスなしのファイル名だけで起動できるというものです。

Start your application by using an alias

一応OSの設定にも出てきます。

「アプリ実行エイリアス」とは

ストアからインストールしたアプリの実行ファイル等はOSが管理するので、アプリの起動は基本的にスタートメニューに作成されるアイコンからか、自動起動に登録するか以外にはできませんが、そのコマンドプロンプト向けの救済策のようなものです。

これだけならコマンドプロンプトを使わせたいケース以外には関係ない話ですが、Hash Padを開発しているときに別の利用法があるのを見つけました。すなわち、これを宛先に指定することでアプリを起動するショートカットを自由に作成できます。

このアプリ実行エイリアスは以下のパスに自動的に作成されるようです。
C:\Users\[ユーザー名]\AppData\Local\Microsoft\WindowsApps

タネ明かしとしては、PATHを一覧表示するとこのパスが入っているので、それでパスなして起動できるというわけですね。

これはフルパスとしては以下のコードで取得できます。これ自体はエイリアスというかシンボリックリンクみたいなもので、実体のあるファイルではないですが、これから直接アプリを起動できるほか、ショートカットのターゲットパスに指定してアプリを起動することもできます。

もう一つ重要な点は、WinRTのAPIにはパッケージされたアプリからしか利用できないものがありますが、これから起動するとパッケージからの起動になることです。実行ファイルを探し出して直接起動した場合はパッケージからの起動にならないので、この点は大きな違いです。

というわけで、アプリ実行エイリアスを使うことでストアにアプリを出すときの難点の一つを解決できます。Hash Padでは、これによりコンテキストメニューの「送る」フォルダーにショートカットを作成しています。

GitHubのWikiブランチへのアクセス

noreply@blogger.com (EMO) — Wed, 14 Oct 2020 10:40:00 +0000

特に難しい話ではないですが、GitHubのレポジトリでWikiを作成すると、wikiというブランチが作成されます。このブランチにリモートのWindowsからアクセスする方法としてはGitHub Desktopが手軽ですが、ぱっと見では分からなかったので、メモです。

初めにパスとしては、そのレポジトリのパスの.gitの前に.wikiを挿入したものになります。したがって、自分のMonitorianを例にとると、レポジトリ自体は
https://github.com/emoacht/Monitorian.gitなので、
https://github.com/emoacht/Monitorian.wiki.gitとなります。

後はGitHub DesktopのAddからClone repositoryを選んで、URLのタブで直接指定してしまいます。

これでクローンしてしまえば、後は普通のレポジトリと同じです。

GitHubの機能や他のサービスを活かしたレポジトリは機能的でいいのですが、それぞれノウハウがあってなかなか面倒です。

Lenovo 500 FHD Webcam

noreply@blogger.com (EMO) — Fri, 12 Jun 2020 05:27:00 +0000

数少ないWindows Hello対応のUSBカメラの新製品であるLenovo 500 FHD Webcamが到着したので、レビューします。この製品に関しては、Lenovo公式から以外の情報があまりないので。

1. 外観

パッケージをLogicool C920sと並べたところ。店頭陳列用に派手なデザインのLogicoolに対して、色もサイズもおとなし目です。

最初にこの製品の名称ですが、Lenovo公式では「Lenovo 500 Full HD Windows Hello対応 Webカメラ」という、どこまでが製品名でどこからが機能説明なのか分からない表記になっていますが、パッケージにある表記が本来の名称なのでしょう。というわけで、「Lenovo 500 FHD Webcam」です。

Windows Hello対応のUSBカメラとしては、長らくマウスコンピューターのCM01とその後継のCM02が実質的に唯一の選択肢で（Logicool Brio Webcamはこれだけのためには高すぎ）、ようやく選択肢が増えたことになります。

DellのU2720QMの上に設置したところ。C920sはカメラ本体が台座の前にあるのに対して、500 FHDは台座の上にあるので、カメラの位置は少し奥になります。

デザイン的には、レンズとマイクのモチーフが盛り込まれたC920sとは対照的に、500 FHDは余分な装飾も凹凸も一切ないミニマルなデザインになっています。

高さはC920sは本来もっと低いのですが、台座のモニターの前に掛ける爪が長く、そのままだと表示域（縁から6mmぐらい）にかかってしまうので、3mmのゴムを挟んで上に上げています。これはC920sの元設計が古くてベゼルレスのモニターが考慮されてないのでしょう。500 FHDの方は台座の爪が短く、そのままで問題ありません。ちなみに、台座の幅はどちらもきっかり45mmです。

首振りは上下のみのC920sに対して、500 FHDはボール雲台式で自由度は高いです。ただ、C920sは俯角が大きく取れるようになっているので、それには及びませんが、台座自体の設置角でも調整幅は増やせるので（油気圧サスペンションの戦車の如く）、問題にはならないかなと。

上面にはLenovoのロゴがうっすら入っています。これは表面仕上げの違いでロゴだけツヤを付けて見せているだけなので、角度によって見えることがあるという程度です。

USBケーブルはC920sが直出しなのに対して、500 FHDはUSB-Cコネクタに挿す形式（USB-C to USB-Aケーブルが付属）で、この方が自由度は高いですが、ケーブルが宙を走ることになって収まりが悪い面もあり、良し悪しという気がします。

2. 機能

カメラには4つ窓があって、中央から左側に向かって普通のカメラ、赤外線カメラ、赤外線ライト、プライバシーライトです。右側にも何かありそうに見えますが、ここには中にプライバシーシャッターがあるので、センサーはないです。

このシャッターは上のつまみを押さえて横にスライドさせると、中のシャッターも動く仕組みです。

シャッターには赤丸があるので、よく見れば閉じているのが分かります。ただ、カメラに赤丸は一般的には録画中を示すサインなので、閉じている状態を示すにはUI的にどうかなという気がします。つまみの大きさから見て、頻繁に変えるというより念のために付いている感じですが。

普通のカメラの撮影中はプライバシーライトが点灯します。

Windows Helloの認識中は、赤外線ライトが点滅します。色はSurface Proと同じく赤ですが、光はもっと強いです。認識はうまく行けば一瞬なので、Surface Proと変わりません。

画質

500 FHDの普通のカメラは、基本スペックとしてはFull HD（1920×1080）で、C920sの1080pモード、Surface Pro 4のフロントカメラと変わりません。

画質については……自分ではそれほど差が分からないというのが実際のところです。C920sはさすがに自動調整がうまく効いているぐらいは分かりますが……一番古いSurface Pro 4のカメラでも映りは悪くないと感じるので。試していて気づいたのは、むしろ映りにダイレクトに影響するのは、カメラというより照明の方かなと。

なお、LogicoolのLogi Captureのようなカスタマイズソフトは付属しません。余談ですが、Logi Captureは、使ってみるまで知らなかったのですが、カメラの設定ソフトではなく、それ自体がカメラ入力を受けて画像をリアルタイムに加工して他のソフトに出力するもので、当然リソースを結構使うのですよね。カメラ入力は他のソフトで直接受けられるので、画像にこだわりがなければ使わなくていいかなと。

互換性

試した範囲では、Microsoft Teams、Cisco Webex、Zoomで入力元に使えるのを確認しました。

なお、C920sとは違ってマイクはありませんが、個人的には別に求めていないので問題ありません。

3. Windows Helloカメラの切換え

自分は数年来、Surface Pro 4に外部モニターを接続して使っていますが、そのときにはSurface Pro 4の画面に被せる形にするので、Surface Pro 4に内蔵のWindows Helloカメラは使えなくなります。これが500 FHDを購入した理由ですが、実はWindows 10には複数のWindows Helloカメラを切り替える機能がないらしく、500 FHDを接続してもそのままではWindows Helloに内蔵カメラを使おうとします。

対処療法として、内蔵カメラをデバイスマネージャーで無効にしてしまえば、代わりに500 FHDが使われるようになるのが分かったので、500 FHDの有無に応じてこれを自動化するツールとしてHello Switcherを作成しました。

emoacht/HelloSwitcher

注意点として、OSのサインイン前には動作できないので、前回サインアウト時の最後の状態は次回サインイン前には変更できません。具体的なケースで言うと、前回サインアウト時に500 FHDがある状態だった場合、内蔵カメラは無効化されているので、次回サインイン時に500 FHDがない場合は、有効なWindows Helloカメラが存在しないことになり、Windows Helloが使えません。こういう場合はPIN認証などでサインインして下さい。サインイン後にこのツールが実行された際に内蔵カメラは有効化されます。

4．評価

まとめると、良い点は以下のとおりです。

ミニマルですっきりしたデザインがとても良い。
Windows Helloカメラとして問題なく使える。
普通のカメラとしても使える。

個人的に悪い点はないですが、一般的な注意点としては以下のとおりです。

カスタマイズソフトは付いてこない。
マイクはない。

以上です。

スマートフォンのモニター用マウント

noreply@blogger.com (EMO) — Thu, 30 Apr 2020 23:45:00 +0000

スマートフォンをウェブカメラの代用としてモニターに固定する方法を思案して工作したところ、これが意外といい出来だったので残しておきます。

モニターはDellのU2720QMで、これにキングジムのDB-200から工作したマウンタを置いて、moto g7を固定したところ。

DB-200の前面にある小物入れというか樋部分は、狭額縁のモニターだと表示域にかかり（サイトの説明では5mmとなっているが、実物は6.5mmあった）、かつ間に挟んで上にずらしても庇みたいになって邪魔なので、3mmぐらい残して切除。
スマートフォンのカメラの位置をなるべく下げたかったので、g7に合わせて現物合わせで穴を開けて嵌め込むようにした。
固定はg7の軟質ケースの弾性による。

工作自体は単純ですが、経験的には、DIYではどうせ精度は出せないので、工作は単純なものほど結果はよいです。

穴はg7がモニターの筐体のアールに合う位置にしてありますが、これは先に試して、このアールに合わせると角度的に丁度いいことが分かっていたので。

DB-200の足は角度を無段階に調整できるように見えますが、実際は中にラッチが仕込まれていて無段階ではなかったので、ゴムワッシャーを間に挟んで自由に調整できるようにしています。これでカメラの角度を多少調整することも可能という見込み。

正面からはこんな感じ。

カメラのモニター上端からの距離は22mm程度なので、ボール雲台式のウェブカメラと同程度です。位置をこれ以上下げるとカメラの視界にDB-200の前端が入ってくるので、DB-200を削る必要が出てきます。

なお、この状態でもあらかじめアイコンが上に出るよう配置しておけば基本的な操作は可能。

これでスマートフォンの固定自体は満足できる状態になりましたが、実際に使っているとスマートフォンを代用することによる遅延が気になってきたので（DroidCamXを720pで使用）、注文してあるウェブカメラが到着すれば使用終了の予定。

Gitのcore.autocrlfの設定

noreply@blogger.com (EMO) — Mon, 13 Jan 2020 06:35:00 +0000

改行コードはWindowsアプリでは便宜的にCrLfに揃えることにしていて、.gitattributesでは「* text=auto」はコメントアウトし、.editorconfigでは「end_of_line = crlf」と設定していますが、にもかかわらず自分が認識しないところでLfに変わっていることがあり、さらにCrLfに修正してVisual Studio上でStageしようとするとStage対象に移動しないまま消える、という問題がしばらく前から起こっていて、少々困っていました。

Git絡みの問題であろうことは想像できましたが、VSの問題か、GitHub Extension for Visual Studioの問題か、Git自体の問題かよく分からず、Gitの設定にある「core.autocrlf」が関係ありそうな気がする一方、説明を読んだ限り関係なさそうに思えたので特に触らずにいました。

それが、まとまった数のファイルをCrLfに修正してcommitした後、PowerShellのCUIからそのcommitを含めてrebaseし、VSでリロードしたら全部またLfに戻っていたという問題が発生したので、思い切って以下のコマンドを実行。

git config --global core.autocrlf false

そうしたら、変な動作が全部消えました。

この設定を意識してtrueにした記憶はないものの、Git環境の構築は何度もやり直してるので、正確なところは不明。Gitの設定への理解不足といわれればそうかもしれませんが、こういう問題が起こるとは想像し難いものがあり、謎動作されるぐらいなら切っておいた方が面倒がないと思われます。

HDDの波形の変化

noreply@blogger.com (EMO) — Mon, 13 Jan 2020 03:57:00 +0000

HDDが性能的にSSDに置いて行かれて久しい現在、それでも3.5インチHDDにはぼちぼちと進化が見られるが、2.5インチHDDには目ぼしい進化は見られない（と思う）。それは仕方ないとして、特に変化は期待せずNAS用のHDDを更新したら、HDDの「波形」について発見があったのでメモしておく。

HDDの「波形」というのは、HDDの速度を計測すると現れる位置固定のパターンのことで、記録面の記録密度に由来するものと個人的に考えているもの。基本概念は以下参照。

記録面と速度の実際

購入したのは東芝の2TBのMQ04ADB200。店はいつものように秋葉原のArk。

9.5mm厚なのでプラッタは2枚で記録面は4。東芝以外も含めて4TBのモデルは存在するが、どれも厚みは15mmのようなので、プラッタは4枚と推測され、したがってプラッタ当たり容量は同じと思われる。

2台のうち1台目のDisk Gazerの結果。上に出ている水色のグラフが最外周（先頭）100GiB、下の黄色が最内周（末尾）100GiBを示す。

まず計測幅が100GiBなのは、初めは先頭10GiBで計測したら水平線だけで波形が出てこなかったので、広げたから。水色の方だけではやや迷うが、黄色の方を見れば特徴的な4つの水平面の波形が分かる。これには注目すべき点が2つあって、

先頭の水平面の長さは約19GiBで、これは以前のHDDより桁違いに長い。4つの水平面を合わせると約71GiBにもなる（水平面ごとの長さは同一ではない）。末尾の4つでも約27GiBとなる。
同じ記録面のものと推測される水平面でも高さが微妙に異なるので、完全に同じ波形の繰り返しではない。

次に2台目のDisk Gazerの結果。こちらも上の赤紫色が最外周100GiB、下の黄色が最内周100GiB。

こちらも同じ特徴を示しているが、赤紫色の方でも4つの水平面の波形が分かりやすい。

これらが何を意味するか。一番シンプルな解釈は、あるゾーンの記録面（この場合は4つある）中のトラックを移動するのに、以前のHDDのように1つの記録面のトラックをある程度使ったら別の記録面に次々に移っていくという、記録面を小刻みに切り替える使い方ではなく、1つの記録面のトラックは（そのゾーンに属する）全トラックを最初から最後まで使った後に次の記録面に移るという、記録面をゾーンの途中で切り替えない使い方になっていることが考えられる。

4つの水平面が1つのゾーンを構成するとして、1台目のように最初のゾーンの容量を71GiB、最後のゾーンの容量を27GiBとし、この間で容量が一定幅で減っていく（正確には2次関数的に減ると思うが）と仮定すれば、1863GiBは38ぐらいのゾーンに分割できる。この数はゾーン数としてあり得なくはない。
水平面ごとに同じ記録面でもゾーンが違うとすれば、高さ＝速度＝記録密度が違うのは普通。概ね末尾に行くにつれ同じ記録面でも微妙に高さが下がる＝速度が遅くなるのは、ゾーンが変わっていると捉えれば自然な推移（同じ記録密度であっても末尾（内周）に行くにつれ線速度が遅くなるので、アクセス速度も遅くなる）。

この記録面の使い方の違いがユーザーにとって何か意味があるかといえば、別に何もないが、個人的には波形の健在を確認できた。

なお、過去には専らHGSTのHDDを見てきたので、ベンダーによる違いも考慮すべきではあるが、過去の東芝のHDDの波形は他社のHDDと基本的には変わらなかった。いずれにしても、そもそも2.5インチHDDの存在自体いつまで続くのか分からないし、ベンダーの違いにこだわる話でもない気がする。

[追記]

今更気づいたが、このMQ04 シリーズは公式スペックによれば、Drive-Managed SMR (瓦記録) 技術とのこと。

ということは、水平面が長いことはSMRと関係がありそうではある。また、SMRだとキャッシュの影響があるかもしれないが、Disk Gazerはリードだけなので関係ないか。

Surfaceのバッテリ問題

noreply@blogger.com (EMO) — Fri, 06 Sep 2019 23:08:00 +0000

スマホやタブレットのリチウムイオンバッテリが膨張する問題は珍しくないが、自分のSurface Pro 4でも発生し、Microsoftで交換してもらったので、記録しておく。

1. 状況

問題に最初に気づいたのは6月頃で、使用期間はほとんど毎日使って2年10か月になる。それまでハードウェア的な問題が起きたことはなかったので、その点は優秀と言えた。

気づいた兆候は、一つはキックスタンドが畳んでも筐体とぴったり合わなくなったことで、フローリングの床に落としたことはあったので、そのときに歪んだかぐらいに思っていた。これは段々ひどくなって、交換に出す直前でこの状態。

もう一つは暗い中で画面の周縁部に顕著なムラが出ることで、経年劣化かと思っていた。これも段々明るい中でもはっきり分かるようになり、画面向かって左側に黄色い模様、最も圧迫された中央に明るい斑点が出てきた。

筐体の歪みなら力をかければ戻せないかなと試みた後で（そう簡単に曲がるような筐体ではなかった）、ふと表と裏の両方に内側から圧力がかかるような原因といえば、バッテリの膨張があったと思い当たった。

表側の膨らみに定規を当てて測ると3mmぐらいで、裏側も同程度だったので、計6mmぐらい膨らんだことになる。

ちなみにBattery reportでは、MANUFACTURERはSMPで、サイクルカウントは225回。容量はDESIGN CAPACITYが38,152 mWhに対し、FULL CHARGE CAPACITYが33,922 mWhだったので、それほど劣化していない感じではある。

2. 手続

MicrosoftのSurfaceのサポートに朝一で電話したところ、昼頃に写真のアップロード先を指示するメールが来る。
側面から表裏を撮った写真とシリアルナンバーの写真をアップロードし、4日後に注文を受け付けたとのメールが来る（注文とは、交換の注文という意味らしい）。翌日Microsoftから電話があり、専用の返送用パッケージを送るので、それを受け取った後、Blu Logisticsという会社に集荷依頼するようにとの説明（返送先は日本国内）。費用は発生しないとのこと（保証期間は切れていたので、この点は太っ腹？）。
返送用パッケージを受け取り。専用というのでどんなものかと思っていたら、確かに専用ではあるけど、梱包自体は簡単なものだった。

梱包はSurfaceのサイズに切り抜かれた台紙に嵌め込んで、銀色の平たい箱を上に載せるだけ。リチウムイオンバッテリの発火リスクを考慮したものっぽい。
Blu Logisticsに集荷依頼の旨を書いたメールを送る。2日後、アリスペッドジャパンという会社から連休前の夜になって集荷の希望日時を確認するメールが来るが、注文番号は正しいのに、依頼人は別の人と間違えていた（管理大丈夫か？）。連休中なら対応可能と返すも反応はなく、休み明けに改めて集荷時間を指定するメールを送ると、2日後以降でないと対応できないという（それなら初めに書いてほしい）。改めて指定するメールを送ると、佐川に集荷を手配したとのこと。
佐川から発送して営業日で3日後にMicrosoftからデバイスを受領したとのメールが来る。翌日にデバイスを発送したとのメールがあり、その2日後に代替品が到着。発送元は東京都内。

以上のうち、Microsoftが自社でやっている部分は迅速だが、引取りを他社に委託している部分は非効率。過去のLenovoでは（現在は知らない）、サポートに引取りを依頼すると梱包資材を持って引取りに来て一発で終わったものが、無駄に手間がかかる。

3. 代替品

代替品は同スペックのSurface Pro 4で、特に使用感なし。

ただし、初めはバッテリが充電されない問題があり、何をしても充電が始まらなかった。デバイスマネージャーでは普通に表示されるものの、Battery reportを取得しようとするとエラーになり、何か問題があるようだった。

色々試すうちに充電は始まったが、直前にやったのはサスペンドからの復帰中に固まったときに電源を抜いたことで、何かのフラグが解除されたのかもしれない。改めてBattery supportを取得すると成功し、MANUFACTURERはDYN、サイクルカウントは「-」だったので、未使用だと思う。DESIGN CAPACITYは38,152 mWhで前と同じだが、FULL CHARGE CAPACITYは40,485 mWhになっていた。

ということで、本体の方が新しくなったのに合わせてタイプカバーも新しくした。

パトリオットパーク（クビンカ戦車博物館）

noreply@blogger.com (EMO) — Tue, 03 Sep 2019 19:22:00 +0000

ロシアのモスクワ郊外にある「クビンカ戦車博物館」といえば、第二次大戦の戦史に興味があれば一度は訪れたい場所ですが、簡単に行けるところでもありません。先日のMAKSのついでに行ってきたので、特にツアー以外で公共交通機関を使って行くことを検討する人のために、説明しておきます。

1．概要

基本情報については、小泉悠著「徹底抗戦都市モスクワ」を読んでください。一言でいえば、モスクワの軍事関係施設のガイド本です。自分も電子版をスマートフォンに入れて持っていきました。

まず「クビンカ戦車博物館」（Танковыи Музей Кубинка）は、現在ではパトリオットパーク（Парк Патриот）の一施設として（飛び地のような形で）組み込まれています。「クビンカ戦車博物館」という略称が有名ですが、地図等での実際の表記はそうではない点に注意が必要です。

ロシア語が主ですが、以下が公式サイト。

Парк Патриот

収蔵していた戦車も、特にドイツ戦車の多くは新たに設置された施設に移動されています。これらの正式名はよく分からなかったのですが、

新しい施設：地図アプリ（Yandex Maps）によればПарк Патриот Музейный комплекс No1、またはチケットの表記によればМузейный площадки No1（英語でいえば、Museum complex No.1、またはMuseum site No.1に相当）。なお、テント張りの仮設構造物。
元の「クビンカ戦車博物館」：地図アプリによればПарк Патриот Музейный комплекс No2（英語でいえば、Museum complex No.2に相当）、またはチケットの表記によればЦентральный музей бронетанкового вооружения и техники（英語でいえば、Central museum of armored arms and technology）。

このNo.1の博物館にティーガーを始めとするドイツ戦車は移動され、No.2に残っていたのはIII号戦車、III号突撃砲、パンター、カール、マウスぐらいでした（2019年8月時点）。したがって、両方行かないわけにはいきませんが、No.1の方が問題でした。

パトリオットパークに関する情報の多くは、年一回のARMY（AРМИЯ）を前提にしているようで、この期間外には当てはまりません。パトリオットパーク（No.2の博物館を除く、新しい方）の中には幾つも施設がありますが、ARMYの期間外に普通に一般人が入れるのはNo.1の博物館だけのようで、それはいいとしても、掲示等にある巡回バスは実際には走っておらず（中を徒歩で移動中に一度も見なかった）、路線バスもありません。シャトルバスがあるような記述も見かけますが、「そんなものはない」

したがって、移動手段は実質的にタクシーのみですが、行きは駅でタクシーを捕まえればいいとして、帰りは駅等から遠いためか、タクシーアプリで呼んでも来てくれません。となると、他の客を乗せてきたタクシーを捕まえるしかないわけですが、そういうタクシーもたまにしか来ず、何とか捕まえて駅に戻りましたが、全く洒落にならない状況でした。

ということで、No.1にタクシーで行くことはお勧めしません。リスクを回避するなら、少々高くついても、ツアー業者を利用した方がよいと思います。もしくは、ARMYの期間中であれば事情は変わってくるでしょうし、他の施設も見られるしで、その方がいいのではないかと。

2. 地理的情報

現地の地理に関しては、駅はKubinka-1（Станция Кубинка-1）を利用することになると思います。No.1には他の駅の方が近いように見えますが、道路網的にKubinka-1駅の辺りが結節点のようなので。

Kubinka-1駅を出ると、早速T-62Mとパトリオットパークの説明板があります。

上の絵ではコンパクトそうに見えますが、実際はかなり広く、下の地図（Yandex Mapsによるもの。以下同じ）の中で、西にあるKubinka-1駅から東南方向に出る線路（電車は走ってない）のTechnical Center駅の近くにNo.2が、Park Patriot駅の近くにNo.1が位置しています。

ちなみに、これだけ見るとNo.1とNo.2の間を直線で移動できそうに思いましたが、実際に行ってみると細い構内道路で、一般車両が走るようなものではないです。

駅からNo.1に車で移動するときは以下のルートになります。Aが駅で、Bがここまではタクシーで入れる地点。

BからNo.1までは徒歩で20分ぐらいかかります。すぐ前の駐車場までツアーの車らしきものが入っていたので、ツアーで来る人は歩かなくて済むようです。

No.1は大きな仮設構造物の各棟が連結されていて、その中央に入口があります。

チケットブースは閉じており、チケットは受付で販売。内部は公式サイトの写真のとおり、スペースに余裕をもって配置され、照明も明るいので、鑑賞条件は良好でした。

各棟の北側に屋外展示場への出入口があり、衛星写真でも点々と見えるように航空機（Su-27、Mig-31、Mig-29他）、車両（T-72、T-80他）等が置かれています。柵はないので、じっくり至近距離から観察可能。航空機は痛みがありましたが、モニノ空軍博物館ほどではなし。

一方、駅からNo.2に行くには以下のルートになります。先の本で実践されていたように徒歩で戻ることも現実的な距離です。丁度客待ちのタクシーがいたので、歩きませんでしたが。

入口は北側にあります。

No.1と違って独立した棟が並んでいる形式ですが、内部は詰込み気味で、光線の状態も悪いので、鑑賞条件は良くないです。

下の配置図では下側が入口で、上の地図と正反対になりますが、入口から見て左側の4棟にソ連（СССР）の戦車が、右側の手前側の棟にアメリカ（США:Сполучені Штати Америки）、カナダ（Канады）、英国（Великобритании）、奥側の棟にドイツ（Германии）の戦車があります。さらに奥側の棟に日本戦車があったようですが、No.1に移動されていました。

ソ連の棟にはレアな実験的車両が多数あります。現用のT-90Aもあり。ドイツの棟は前述のとおりNo.1に移動されたものが多く、スカスカ。

所要時間はどこまでじっくり見て回るかによりますが、No.1の方はさくさく回れば屋外展示を含めて2時間半、取りこぼしなくディティールまで写真に収めようとすれば5時間ぐらい。No.2の方は一台一台をきれいに写真に収められる状態でないこともあり、急げば1時間、丁寧に回れば2時間ぐらいでしょうか。No.1との移動がスムーズに行くことを条件に、両方を1日でまあ大体見て回ることが可能です。

以上、参考までに。

Microsoftストアのサブスクリプション情報の取得

noreply@blogger.com (EMO) — Sun, 12 May 2019 13:32:00 +0000

Microsoftストアでは、しばらく前からアプリのアドオンのサブスクリプション販売が可能になっています。アプリ自体を販売する場合は、アプリ側の対応はそれほど手間ではないですが、アドオン（アプリ内販売となる）でかつサブスクリプションとなると、割と面倒な対応が必要になります。

ストアの販売用のAPIは新旧の2種類ありますが、Desktop Bridgeのアプリを前提とするならば、新しいWindows.Services.Storeの方を使うことになります。このAPIはStoreContextオブジェクトのメソッド群で構成され、それなりにサンプルがありますが、肝心な情報の取得方法が抜けているので、その補完がお題です。

In-app purchases and trials

1. サブスクリプションのライフサイクル

サブスクリプションの状態によってアドオンの動作を切り替えるだけなら、

使用権があるか否か

が分かれば十分で、詳しいことはウェブ上のMicrosoftアカウントを見てくれ、と割り切るやり方もなくはないです。

ただ、使用期間といっても、サブスクリプションのライフサイクルを考えると、以下のような期間に分かれます（サブスクリプションは自動更新が既定で、現在の期間の使用期限までにキャンセルされない限りは自動更新され、また、キャンセルされた後も現在の期間の使用期限までは使用できる）。

試用期間
試用期間中にキャンセルされた後の使用期限までの期間
試用期間/有償期間後の自動更新により開始された有償期間
有償期間中にキャンセルされた後の使用期限までの期間

サブスクリプション販売の場合、ユーザーの当然の関心事は意図せずに課金されないことだと思います。使用期限前にキャンセルするつもりだったのが、しそこねるといったケースですが、これを避けるにはユーザーが以下の情報を簡単に確認できるようにするのが望ましいです。

現在が（無償）試用期間か有償期間か
現在の期間の使用期限
自動更新が有効になっているか（キャンセルされていないか）否か

これらの正確な情報の取得方法が、このAPIのサンプルでは説明されていません。仕方ないので試行錯誤した結果が以下ですが、これもストアのサーバー次第でいつ変わってもおかしくないので、そのつもりで。

2.1. 使用権があるか否か

これだけなら簡単で、GetAppLicenseAsyncメソッドで可能です。

Get license info for apps and add-ons

これで取得できるStoreAppLicenseオブジェクトのうち、アドオンのライセンス情報はAddOnLicensesプロパティのStoreLicenseオブジェクトにあります。ここに目的のアドオンのものがあれば、使用権があるということです。なお、このSkuStoreIdプロパティはStore IDの後にSKU番号が引っ付いたフォーマットで、Store IDそのままではないので要注意。

このメソッドだけは結果がキャッシュされていて、オフラインでも使うことができます。したがって、使用権の確認だけできればいいという場合は、アプリの起動時にこれを実行するだけというシンプルなやり方もあり得ます。

2.2. 現在が試用期間か有償期間か

これにはGetUserCollectionAsyncメソッドが使えます。

Get info for add-ons for the current app that the user has purchased

これで取得できるStoreProductオブジェクトに含まれるStoreCollectionDataオブジェクトのIsTrialプロパティが目的のものです。サンプルは以下のとおりです。

この方法に辿り着く前にStack Overflowで質問したのですが、答えを付けたMSFTの人には理解されなかったようで。

How to determine whether add-on subscription of Windows Store app is in trial period or in paid period

このメソッドは経験的には、有償期間に入った後にキャンセルされた後は使用期限前であっても（上記の期間4.のケース）そのStoreProductを返してきません。また、オフラインでは使えないので（実行の度にストアのサーバーと通信するらしい）、必要ならローカルに記録しておく必要があります。

2.3. 現在の期間の使用期限

上記のStoreLicenseにあるExpirationDateプロパティがいかにも使えそうに見えますが、これが曲者で、これ単体では使えません。経験的に整理したところでは、サブスクリプションの自動更新が有効のときは正しい日時から3日後の日時になり、無効のときは大体正しい日時（1日のズレあり）になるようです。

この点からすると、自動更新が有効のときは課金処理の遅延を見越して数字をいじっているのではないかという合理的な疑いがありますが、こういう辻褄合わせのために大元のAPIのデータをいじるのはやってはならないことだと思います。さらに問題なのは、StoreCollectionDataのEndDateプロパティも含め、他のメソッドで取得できる使用期限の日時にも同じ問題があり、どれも信用できないことです。

したがって、自前で計算するしかないわけですが、そのためには、

現在の期間の開始日
現在の期間の長さ

が必要になってきます。

まず現在の期間の開始日は、StoreCollectionDataのStartDateプロパティが使えます（上記サンプルのとおり）。なお、これにはAcquiredDateプロパティもありますが、これは実際に購入した日時を指すようで、StartDateとは微妙にズレがあります。このズレの法則性はよく分かりませんが、この計算のための開始日としてはStartDateの方が正しいようです。

次に現在の期間の長さは、先に現在が試用期間か有償期間かを判別する必要がありますが、これは上記のとおりStoreCollectionDataのIsTrialプロパティで分かります。期間の長さは、GetStoreProductsAsyncメソッドで取得できるStoreProductオブジェクトで分かります。

Get info about subscription add-ons for the current app

なお、この例にあるGetAssociatedStoreProductsAsyncメソッドでは有償期間の長さは分かりますが、一旦試用期間に入った後は試用期間の長さは分かりません。というのも、このメソッドが返すのは現在の期間の次に購入可能なSKUだけなので、一旦試用期間に入った後は、次にはもう試用期間はなく、試用期間のSKUは取得できないからです。

この2つが分かれれば、後はStoreDurationUnitに気を付けて計算するだけです。

なお、上記のとおり期間4.のケースではUserCollectionDataは取得できませんが、このケースでは自動更新が無効となっている結果、StoreLicenseのExpirationDateプロパティが大体正しい日時を示すので、それをそのまま使えばいいでしょう。

[追記]

自分で計算した日時とMicrosoftのサーバーで期限切れまたは自動延長の処理が行われる日時にはズレがあるので（1日以内）、アプリで期限切れに伴う処理を行う前にはこのズレを考慮する必要があります。

2.4. 自動更新が有効になっているか否か

これはどこにも説明はないですが、情報はあります。

このAPIで取得できるオブジェクトにはExtendedJsonDataプロパティがあり、ストアのサーバーから取得したらしきJSONが格納されています。この中にはそのオブジェクトのプロパティに出てこないものもあり、そういうのはこれを直接見て使えということですね。

Schema for StoreProduct, StoreSku, StoreAvailability, and StoreCollectionData

StoreCollectionDataのJSONはこのスキーマのcollectionDataに相当するようですが、この中にautoRenewの要素があります。これが経験的には自動更新の状態を示していて、これが存在してtrueなら有効、存在しないかfalseなら無効です。上記のサンプルでは、JSON全体をパースする必要もないので、該当部分を正規表現で抽出して判別しています。

3. まとめ

以上のように必要な情報は取得できるようになりましたが、ここに至るまでの試行錯誤に相当な時間を費やさざるを得なかったので、正直どうかと思います。わざわざ新APIを作ってサンプル等もそれなりに用意したにもかかわらず、詰めが甘いというか。結局、ストアのサーバーにある情報をどう引っ張ってくるかという問題なので、一発で必要な情報が揃うようにした方がクエリ数も減っていいと思いますが。

こんな当てにならないAPIに頼るより、購入日をローカルに記録しておけば後は何とでもなるのではないか、と思ったこともありましたが、調べていくにつれそのやり方ではむしろ色々なケースで整合性を保つのが大変すぎると気づいて断念しました。

なお、Desktop Bridgeのアプリの場合でも、Windows Application Packaging Projectを使えばこのAPIのデバッグ実行はUWPと同じようにできるので、それ自体は難しくないです。

Package a desktop application by using Visual Studio