2019/09/07

Surfaceのバッテリ問題

スマホやタブレットのリチウムイオンバッテリが膨張する問題は珍しくないが、自分の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. 手続
  1. MicrosoftのSurfaceのサポートに朝一で電話したところ、昼頃に写真のアップロード先を指示するメールが来る。

  2. 側面から表裏を撮った写真とシリアルナンバーの写真をアップロードし、4日後に注文を受け付けたとのメールが来る(注文とは、交換の注文という意味らしい)。翌日Microsoftから電話があり、専用の返送用パッケージを送るので、それを受け取った後、Blu Logisticsという会社に集荷依頼するようにとの説明(返送先は日本国内)。費用は発生しないとのこと(保証期間は切れていたので、この点は太っ腹?)。

  3. 返送用パッケージを受け取り。専用というのでどんなものかと思っていたら、確かに専用ではあるけど、梱包自体は簡単なものだった。


    梱包はSurfaceのサイズに切り抜かれた台紙に嵌め込んで、銀色の平たい箱を上に載せるだけ。リチウムイオンバッテリの発火リスクを考慮したものっぽい。

  4. Blu Logisticsに集荷依頼の旨を書いたメールを送る。2日後、アリスペッドジャパンという会社から連休前の夜になって集荷の希望日時を確認するメールが来るが、注文番号は正しいのに、依頼人は別の人と間違えていた(管理大丈夫か?)。連休中なら対応可能と返すも反応はなく、休み明けに改めて集荷時間を指定するメールを送ると、2日後以降でないと対応できないという(それなら初めに書いてほしい)。改めて指定するメールを送ると、佐川に集荷を手配したとのこと。

  5. 佐川から発送して営業日で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になっていた。

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

2019/09/04

パトリオットパーク(クビンカ戦車博物館)

ロシアのモスクワ郊外にある「クビンカ戦車博物館」といえば、第二次大戦の戦史に興味があれば一度は訪れたい場所ですが、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日でまあ大体見て回ることが可能です。

以上、参考までに。

2019/05/12

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

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

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

サブスクリプションの状態によってアドオンの動作を切り替えるだけなら、
  • 使用権があるか否か
が分かれば十分で、詳しいことはウェブ上のMicrosoftアカウントを見てくれ、と割り切るやり方もなくはないです。

ただ、使用期間といっても、サブスクリプションのライフサイクルを考えると、以下のような期間に分かれます(サブスクリプションは自動更新が既定で、現在の期間の使用期限までにキャンセルされない限りは自動更新され、また、キャンセルされた後も現在の期間の使用期限までは使用できる)。
  1. 試用期間
  2. 試用期間中にキャンセルされた後の使用期限までの期間
  3. 試用期間/有償期間後の自動更新により開始された有償期間
  4. 有償期間中にキャンセルされた後の使用期限までの期間
サブスクリプション販売の場合、ユーザーの当然の関心事は意図せずに課金されないことだと思います。使用期限前にキャンセルするつもりだったのが、しそこねるといったケースですが、これを避けるにはユーザーが以下の情報を簡単に確認できるようにするのが望ましいです。
  • 現在が(無償)試用期間か有償期間か
  • 現在の期間の使用期限
  • 自動更新が有効になっているか(キャンセルされていないか)否か
これらの正確な情報の取得方法が、このAPIのサンプルでは説明されていません。仕方ないので試行錯誤した結果が以下ですが、これもストアのサーバー次第でいつ変わってもおかしくないので、そのつもりで。

2.1. 使用権があるか否か

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

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

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

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

この方法に辿り着く前にStack Overflowで質問したのですが、答えを付けたMSFTの人には理解されなかったようで。
このメソッドは経験的には、有償期間に入った後にキャンセルされた後は使用期限前であっても(上記の期間4.のケース)そのStoreProductを返してきません。また、オフラインでは使えないので(実行の度にストアのサーバーと通信するらしい)、必要ならローカルに記録しておく必要があります。

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

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

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

したがって、自前で計算するしかないわけですが、そのためには、
  • 現在の期間の開始日
  • 現在の期間の長さ
が必要になってきます。

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

次に現在の期間の長さは、先に現在が試用期間か有償期間かを判別する必要がありますが、これは上記のとおりStoreCollectionDataのIsTrialプロパティで分かります。期間の長さは、GetStoreProductsAsyncメソッドで取得できるStoreProductオブジェクトで分かります。
なお、この例にあるGetAssociatedStoreProductsAsyncメソッドでは有償期間の長さは分かりますが、一旦試用期間に入った後は試用期間の長さは分かりません。というのも、このメソッドが返すのは現在の期間の次に購入可能なSKUだけなので、一旦試用期間に入った後は、次にはもう試用期間はなく、試用期間のSKUは取得できないからです。

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

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

[追記]

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

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

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

このAPIで取得できるオブジェクトにはExtendedJsonDataプロパティがあり、ストアのサーバーから取得したらしきJSONが格納されています。この中にはそのオブジェクトのプロパティに出てこないものもあり、そういうのはこれを直接見て使えということですね。
StoreCollectionDataのJSONはこのスキーマのcollectionDataに相当するようですが、この中にautoRenewの要素があります。これが経験的には自動更新の状態を示していて、これが存在してtrueなら有効、存在しないかfalseなら無効です。上記のサンプルでは、JSON全体をパースする必要もないので、該当部分を正規表現で抽出して判別しています。

3. まとめ

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

なお、Desktop Bridgeのアプリの場合でも、Windows Application Packaging Projectを使えばこのAPIのデバッグ実行はUWPと同じようにできるので、それ自体は難しくないです。
こんな当てにならないAPIに頼るより、購入日をローカルに記録しておけば後は何とでもなるのではないか、と思ったこともありましたが、調べていくにつれそのやり方ではむしろ整合性を保つのが大変すぎると気づいて断念しました。