azukipochette's weblog

memory dump (mini)

VMWare Workstation で Docker 生活

はじめに

こん**わ。

なんだか VMWare 自体がやる気がないように見える VMWare Workstation。 Docker も Hyper-V 対応になって、時代は Hyper-V なんじゃないの...と思い出しているかもしれない皆様、いかがお過ごしでしょうか。

私はしばらくの間 Docker は VMWare Workstation 上で使えないのだと思っていて、Vagrant + VMWare Workstation で CoreOS を動かしてその上で Docker を扱っていましたが、実は VMWare Workstation でも Docker が扱えることがわかったので、今日はこの話をまとめます。

Docker Machine VMWare Workstation Drive の導入

世の中には VMWare 愛のある人がいるもので、Docker 用の VMWare Workstation ドライバーを書いてくれています。

Docker for Windows というのは簡単に言うと、docker-machine というコマンドを使って Docker を動かす Linux 仮想マシンを起動して、その環境を docker コマンド経由で操作するようなことをしています。 通常、docker-machine コマンドのドライバーは Hyper-V か VirtualBox なわけですが、これを上記の docker-machine-vmwareworkstation を使うことで、VMWare 上で動作する仮想マシンを用意することができます。

インストール手順は、上記の GitHub のページの "Installation" に書いてあるので読んでください。 なお、最初にある "Install Docker Toolbox" というのは、以下にあります。

start.sh のスクリプトはまるっと置き換えてしまえば大丈夫です。

docker-machine-driver-vmworkstation.exe はパスが通っているフォルダーに置くか、docker-machine.exe のあるフォルダーのどちらかに置くことになりますが、私は docker-machine.exe のフォルダに直接置いています。*1

docker-machine を実行する

docker-machine コマンドを使って、docker を動かす Linux (boot2docker) 仮想マシンを作成します。

docker-machine create --driver=vmwareworkstation default

私は既定のまま使っていますが、ディスクやメモリ、CPU 数などはパラメータで変更可能です。詳しくはこちらも GitHub のページの記載を見てください。 実行すると以下のような流れで仮想マシンが作成されます (それなりに時間がかかります)。

Running pre-create checks...
Creating machine...
(default) Copying C:\Users\<YourName>\.docker\machine\cache\boot2docker.iso to C:\Users\<YourName>\.docker\machine\machines\default\boot2docker.iso...
(default) Creating SSH key...
(default) Creating VM...
(default) Creating disk 'C:\Users\<YourName>\.docker\machine\machines\default\default.vmdk'
(default) Virtual disk creation successful.
(default) Starting default...
(default) Waiting for VM to come online...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env default

作成が完了しているかどうかを念のため確認してみます。

docker-machine ls

以下のような結果が帰ってくるはずです。

NAME      ACTIVE   DRIVER              STATE     URL                         SWARM   DOCKER        ERRORS
default   -        vmwareworkstation   Running   tcp://192.168.32.139:2376           v18.05.0-ce

次に、docker-machine create のレスポンスの最後にあるように、作成した仮想マシン上で docker コマンドが使えるように接続します。

docker-machine env default

以下のような結果が帰ってきます (実はこの記述は置き換えた start.sh の中に書いてあります)。

SET DOCKER_TLS_VERIFY=1
SET DOCKER_HOST=tcp://192.168.32.139:2376
SET DOCKER_CERT_PATH=C:\Users\<YourName>\.docker\machine\machines\default
SET DOCKER_MACHINE_NAME=default
SET COMPOSE_CONVERT_WINDOWS_PATHS=true
REM Run this command to configure your shell:
REM     @FOR /f "tokens=*" %i IN ('docker-machine env default') DO @%i

"Run this command to configure your shell" と書かれているように、表示されたコマンドを次のように実行します。

@FOR /f "tokens=*" %i IN ('docker-machine env default') DO @%i

これで、Docker コマンドを実行する準備ができました。

docker コマンドを試す

実際に docker コマンドが使えるかどうかを hello-world というイメージを使用して確認します

docker run hello-world

すると、以下のような結果が返ってきます。

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
9bb5a5d4561a: Pull complete
Digest: sha256:f5233545e43561214ca4891fd1157e1c3c563316ed8e237750d59bde73361e77
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

これで、無事に docker が使えることが確認できました!(ヤッタ!)

ホストとコンテナのフォルダを共有する

ホスト (Windows) のフォルダーをコンテナ上で扱えないと不便ですよね。

なぜか Docker Machine VMWare Workstation Drive の README.md には記載がないのですが、docker-machine コマンドで仮想マシンを作成したときに、VMWare の機能を使用して C:\Users フォルダーが /Users として共有されています。これまでに説明したように、"Windows <-> Linux (boot2docker) 仮想マシン <-> Container" という流れなので、docker コマンドの --volume で /Users をマッピングすればいいことになります。

たとえば、以下は ubuntu コンテナ上で Windows 上の C:\Users を /share としてマッピングする時のコマンドです。

docker run --name mycontainer -v /Users:/share -it ubuntu /bin/bash

なお、Windows の世界の人は忘れがちですが、大文字・小文字を区別するので、"/Users" とするのがポイントです。

"C:\Users" 配下ではないフォルダーをマウントしたい

上記を見て、「え? C:\Users 配下しか使えないの?」と思った方々、私たちには mklink コマンドがあります。

これは、シンボリックリンクを作成するコマンドです。シンボリックリンクというのを知らない人に簡単に説明すると、特定のフォルダーに実態があるものを、あたかもそのフォルダーにあるかのようにリンクを作成するものと思ってください。たとえば、"D:\Works" を使いたい場合には、まず C:\Users 配下にシンボリックリンクを作成すればよいことになります。

以下は、自分のユーザープロファイル配下に Share フォルダーがあるように D:\Works フォルダーをリンクした例です。

mklink/d C:\Users\<YourName>\share D:\Works

あとは docker コマンド実行時に -v を使ってマッピングすればよいだけです。

docker run --name mycontainer -v /Users/<YourName>/share:/share -it ubuntu /bin/bash

これで、楽しく Docker が使えますね。

それでは、楽しい Docker ライフを。Enjoy!

*1:どうせ start.sh ファイルの内容を置き換えしているし、いいかなという感覚で置いています。ちなみに、変更していなければ既定の場所は "C:\Program Files\Docker Toolbox" です。

Windows 10 Version 1803 に "vagrant ssh" するための base box 設定方法

OpenSSH Server のインストール

以下の手順を実施する。

  1. "Settings" アプリを開く
  2. [Apps] を開く
  3. [Manage optional features] をクリックする
  4. [Add a feature] をクリックする
  5. 表示される一覧から "OpenSSH Server" を探し、クリックする
  6. [Install] をクリックする
  7. インストールが完了するまで待つ

OpenSSH Server を自動的に開始する

以下の手順を実施する。

  1. "services.msc" を起動する
  2. "OpenSSH SSH Server" を探し、プロパティを開く
  3. [Startup type] を "Manual" から "Automatic" に変更する
  4. (必要に応じて) [Start] をクリックし、サービスを起動する

Base Box 用の公開キーを設定する

Vagrant の "Creating a Base Box" (https://www.vagrantup.com/docs/boxes/base.html) にある記載のとおり、GitHub の insecure keypair (https://github.com/hashicorp/vagrant/tree/master/keys) にある公開鍵 (vagrant.pub) を以下の手順で配置する。

  1. https://github.com/hashicorp/vagrant/tree/master/keys にアクセスする
  2. "vagrant.pub" をダウンロードする
  3. PowerShell を起動する
  4. 以下のコマンドを実行する
  5. ダウンロードした vagrant.pub を "authorized_keys" に名前を変更して保存する
cd C:\Users\vagrant
mkdir .ssh
cd .ssh

おまけ

VMWare desktop における guest-os_type のリストは存在しないが、GitHub 上にある open-vm-tools のコード内にそれらしき定義が存在していることをたまたま発見した。 たとえば、Windows 10 の場合、"開発中のコード名は Windows 9 だったので"...と記載されており、実際に VMWare Workstation 14 Pro で Windows 10 の VM を作ると guest-os-type が "Windows9" になっている。

Git Virtual File System(GVFS) の使い方

GVFS (Git Virtua File System) の使い方を日本語で載せておく。 また、GVFS 利用時の注意点もまとめておく (注意点や制限事項などは 2018/5/28 時点でのもの)。

利用条件

  • 使用 OS が Windows 10 Version 1703 以降であること

GVFS は OS の仕組みを利用しているため、現時点で Windows 10 (Version 1703) 以降でなければ使用できない。

  • Visual Studio Team Services を使用すること

GVFS に対応するためには、使用する Git サービスが GVFS プロトコルに対応している必要がある。現時点では、Microsoft が提供している Visual Studio Team Services (VSTS) のみが対応しており、GitHub などでは利用することができない *1

インストール方法

GVFS を利用するには、マイクロソフトが作成している GVFS対応版の Git for Windows を使用する必要がある。Git 公式 (http://www.git-scm.org) で公開されているものでは使用できないので注意が必要。

GVFS 対応版の Git for Windows は以下の GitHub 上のリポジトリから入手できる。このリポジトリは基本的に Git-for-Windows/Git の fork であり、GVFS 以外についての機能は同じである。

Git for Windows インストール後、GVFS をインストールする。GVFS は以下の GitHub 上のリポジトリからダウンロードできる。

制限事項

現在の GVFS には利用上の制限が 2 つ存在する (正確には 3 つ存在する)

  1. リポジトリで clean/smudge フィルターが有効でないこと
  2. リポジトリの直下 (ルート) に "* text" の行を含む .gitattributes ファイルが存在すること
    • 改行コードの変換が無効であること (* text=false)

特に最後の改行コードについては、Visual Studio によって自動的に作成される .gitattributes ファイルでは "* text=auto" となっており注意が必要である。*2

改行コードの設定が問題で失敗した場合は、以下のエラー コードが表示される。

Error: Could not complete checkout of branch: master, fatal: CRLF conversions not supported when running under GVFS

使い方

Git クローンする時に git clone の代わりに gvfs clone を使えばよい。

実行結果の例を以下に示す。

PS C:\Works\GVFSTest> gvfs clone <Repository Url>
Clone parameters:
  Repo URL: <Repository Url>
  Branch:       Default
  Cache Server: Default
  Local Cache:  C:\.gvfsCache
  Destination:  C:\Works\GVFSTest\MonoBuildTest
Authenticating...Succeeded
Querying remote for config...Succeeded
Using cache server: None (<Repository Url>)
Cloning...Succeeded
Fetching commits and trees from origin (no cache server)...Succeeded
Attaching PrjFlt to volume...Succeeded
Validating repo...Succeeded
Mounting...Succeeded
Registering for automount...Succeeded

取得後は、通常の Git コマンドが使用できる。 なお、git clone した場合は直下にコードリポジトリのソースコードが表示されるが、GVFS の場合は "<root>\src" 配下に作成されるのでコマンド実行時は注意が必要 ("cd <root>\src" すること)。

なお、ローカルからリポジトリを削除したい場合、フォルダーを削除する前にリポジトリ配下で次のコマンドを実行してアンマウントしなければならない。*3

gvfs unmount

macOS と Linux 対応について

macOS と Linux への対応については、Microsoft と GitHub が共同で作業を進めている状況だが、現時点では対応していない。

状況としては、macOS 対応のほうが進んでいる様子。

*1:GitHub、GitBucket ともに対応は計画されているが 2018/5/28 時点では利用できない

*2:text=auto の場合、Git に改行するかどうかをゆだねる形になっており、git 設定で as-is (autoCRLF=false) であれば良いように思うかもしれないが false でなければエラーとなる

*3:消そうとすると Windows にファイルが使用中といわれる

SONY WF-1000X は控えめに言って買いじゃない

どうも、こん**わ。

AirPods 以降、完全ワイヤレス イヤホン(トゥルー ワイヤレスとか、フル ワイヤレスとか用語が錯綜してますが) が人気ですね。

私はコンビニのモスキート音が聞こえないぐらいの音感なので、音質よりは実用性重視なのですが、その視点でソニーの完全ワイヤレス イヤホン WF-1000X を買いました。 使っておおよそ半年以上経過したので、私の WF-1000X についての思いをまとめておこうと思います。

私はすでに AirPods を持っていたのですが、髪の短い私には "耳からうどん" がダサすぎて別のを探していました。 そこに、完全ワイヤレスなのにノイズキャンセリング対応という "これでもか!"な多機能イヤホンである WF-1000 を見つけ購入した次第です。

ソニー的にはまだ現役商品のようですが、Amazon.co.jp に行くと後続商品として WF-SP700 をおすすめされる状況なので、WF-1000X をわざわざ買うとはあんまり思えませんが...結論から言うと購入はおすすめしません

以下が主な理由です。

  1. あまりノイズキャンセリングの効果を実感できない
  2. バッテリーの持ちが悪い
  3. ケースの作りが悪い
  4. ファームウェア更新の仕組みがひどい

それぞれ詳しく話します。

あまりノイズキャンセリングの効果を実感できない

効果がないわけではありませんが、そもそも耳栓型 (カナル型) イヤホンなので、外音はかなり聞こえなくなります。 WF-1000X にはアンビエントサウンドという外音取り込みモードというのが搭載されており、これと切り替えるとはっきりした違を感じますが、いわゆるヘッドフォン型のノイズキャンセルなどで体験する「おおっ!」というようなノイズキャンセリングではありません (そもそも他の完全ワイヤレス型イヤホンに搭載されている外部の音を拾うモードなのか、単純にノイズキャンセリング無効なのかも良くわからない)。もし、ノイズキャンセリングを理由に購入する場合は、どの程度なのかを店頭なりで試してから買うことを強くお勧めします。

バッテリーの持ちが悪い

完全ワイヤレス型なのだから当然だろうと思うかもしれませんが、ほかの完全ワイヤレス型イヤホンに比べても悪いです。 連続再生時間は 3 時間ということになっていますが、一方の AirPods は 5 時間です。実際の体感としては、2 倍以上の違いを感じるほどです。 また、急速充電にも対応しておらず、本体充電に 1.5 時間、ケースを含む完全充電に 3 時間必要です。一方、AirPods は急速充電に対応しており、15 分間充電すると 3 時間使えます。もう何か単位かなにかが間違っているんじゃないかと思うぐらいの差です。

ケースの作りが悪い

ケースに本体を収納するとオフになり充電が開始されるという、完全ワイヤレス タイプではありがちの仕様ですが、このケースがかなりイケてません。 カチッとしっかり音がするようにハメないとオフにならず電源がはいったままの状態となり、ケースを開けたらバッテリーがない!ということになります。カチッと音がしたつもりでも充電中を示す赤いランプがつくのを確認しないと安心できないぐらいで、私は何度も持ってきたのにバッテリー不足という状態に陥りました。

ファームウェア更新の仕組みがひどい *1

完全ワイヤレス型イヤホンでもそもそもファームウェア アップデートに対応していなかったりするので、ちゃんと専用アプリが用意されており、機能強化もファームウェアアップデートするのはさすがソニーと言ったほうがいいのかもしれませんが、iPhone におけるアップデート体験と Android の体験が違いすぎます。 iPhone でアップデートすると Android の約 3 倍の時間がかかります。そして、何より頻繁に失敗します。私はこのアップデートのために Android 端末を用意したぐらいですが、普通の人ならあきらめてしまうレベルなんじゃないかと思うほどで、よくこれで製品テストがパスできたなと思っています。

他の完全ワイヤレス型イヤホンと比較すると、この点は明らかです。例えば、AirPods の場合は iPhone 限定なので条件が違いますが、気が付かないうちに勝手にファームウェアがアップデートするようになっています 。Bose の場合は、ソニーの方式に近い専用アプリ型ですが、ファームウェアダウンロードは曲を聴きながら行えます。また、端末への送信とアップデートもそれほど時間はかかりません。


最後に少しだけ良い点を。

やはり、ソニーだなと思うのは本体のデザインがオシャレです。耳からうどんとは大違いです。 耳にカナブンとか、次期機種の WF-SP700 は耳からソラマメとかいろいろ言われていますが、耳からうどんよりははるかに目立ちません。

というわけで、オシャレだからでどうしてもこの WF-1000X が欲しいのだという方はぜひ店頭でノイズキャンセリング性能を確認しつつ、2 万円という金額を出すかどうかご検討していただくと後悔が少なめではないかなと思います。

ではでは。

*1:私はファームウェア/ソフトウェア屋さんだったので、特にここが気になりました

海外購入の Surface Book が故障したときの涙の物語

プロローグ (序文)

みなさま、お久しぶりです。

IT界隈の皆様ですと、英語キーボードなどを理由に海外で PC を購入しているよという方も多いのではないでしょうか?かくいう私も最近、Surface Book 2 というマイクロソフト製の新しいノート PC を海外購入しました。 今日は、そんな私が修理依頼をしてから、新しい PC が戻ってくるまでの顛末を物語りとしてお話しようと思います。この話が同じ事象が発生した皆様に有益だと幸いです。

Surface Book 2 壊れる

ある日...Surface Book で文書を書いていると、一部のキーが反応しないことに気がつきます。 Surface Book のドッキングがおかしいのかな?ハードウェア リセットすれば治るのかな?と検索して試してはみても、うまくいきません。切り分けとして、外付けキーボードをつなげて打つと入力OK、そして UEFI 画面で入力しても内蔵のキーボードでは同じキーが反応しないことを確認...なんということでしょう、これはどうみてもハードウェア不良です。

ハードウェア不良は自分ではどうにもならないので、早速 Surface サポートの方に連絡しようと心に決めます。

日本の Surface サポートに連絡する

まぁ、もちろん私もいきなりサポートを受ける前にインターネット上で同じような人がいないかを調べるわけです。すると...海外で購入した場合は、Surface Pro は交換の対象にしているが、Surface Book は交換対象にしていないことがわかります。まぁ、どうみてもキーボードが原因です。要するに、英語キーボードの替えが日本にないのです。

ちなみに、インターネット上にはマイクロソフトがひどいと書かれている記事がたくさんありましたが、一応マイクロソフトの肩をもつとマイクロソフトはちゃんと購入した国でしかサポートが受けられないよと明記しています。

Q : 保証または Microsoft Complete は、Surface を購入した国以外で適用されますか?

A : いいえ、Surface 標準の制限付き保証および Microsoft Complete は、Surface を購入した国でのみ適用されます。

出典 : Surface の保証: よく寄せられる質問

そう考えると、代替可能なデバイスがあるなら交換してあげようという Surface のサポートを「神サポート!」というのはわかるにしても、「Surface Book は交換してくれないからマイクロソフトしね」というのは少々乱暴だと私は思います。今時、国際企業なんだからどこの国で買っても交換してくれよーと思うかも知れませんが(私も少し思いますが)、本来扱っていない国の在庫を常に保持しておくコストやら商品交換するシステム仕組み作り、国際郵便を扱う送料・手数料など...を考えると、企業としてそこまでやる義務はないね、という気持ちもわからなくはありません。

なお、この話とは別に私は日本でも普通に英語キーボードを買えるようにしてください!とはとても思います...。

さて、日本のサポートは対応してくれないかもしれないことは上記の内容で解っている私ですが、今は日本にいるので、まずは日本語で聞いてみようと Surface 担当者に連絡します。

最近は、オンライン チャットに対応しているようで、こちらでサポートをうけました。 担当者の方はなかなかいい感じの人で、「キーの一部が反応しない。ハードウェア リセットと脱着は試したけどNG。外付けキーボードなら問題ない。UEFI画面でも事象が発生する。」と簡単に伝えると、「なるほど、それは確かにハードウェア不良ですね」とアッサリ納得してくれました。 大抵の PC サポートは、こちらがどんなに事前に調べたと伝えても、ツールを実行してみろだの、出荷時に戻せだの行ってくるものです。

「では新しい PC を手配しますね」と言われるので、「(おや、Surface Boook も修理対象なのか?)」と思いつつ、型番を伝えると、処理が完了したと言われます。

まぁ、私の心の声はお察しのとおり...マジか!やったー!!です。

Surface のような近年の PC は、小型化の代償にマシンを解体して修理ということはできないようです (iPhone なんかもそうだそうな)。なので、交換処理になると言われます。まぁ、新しい PC に交換してくれたほうがいいので、断る理由はありません。

Surface の交換は、現在の壊れた本体を郵送すると、新しい本体がやってくるという仕組みだそうです。 連絡先を教えてもらい、早速郵便局で手続きをし、配送処理をします。

さて、後は新しい PC を待つだけです!...ウフッフー!

テンション高めの私でしたが、この翌日に届くメールに驚愕するのです...。

壊れた PC が壊れたまま戻ってくるまで

「交換できる PC がないので手続きはキャンセルされました」

私はメールの文面をキョロキョロしながら見直します..."キャンセルされました...?"。

「ついましては、故障した PC をご返送しますので、別途お客様にて購入国のサポートにお問い合わせください」

...はい、そうなりましたか。

つまり、受付してしまったことがミスで本来は交換処理できるものではないわけです。上記に引用したとおり、保証は購入国でしかうけられないというわけなので、彼らの対応は間違っていません。

まじかよー!受け取ったなら、交換するまでやってくれよー!

と私が心の中で思わなかったわけではありませんが、まぁそこを求めるのは間違っているわけなので、戻ってくるのを待つしかありません。

問題はこの待ちで...なんと「返送する」と言われてから、1 週間たっても返送されません。「PC が帰ってこない = 海外で手続きを始められない」わけで、さすがにこのときは参りました。

マイクロソフトはなぜかメールで連絡してくるのに、なぜかメールでは回答できないらしく電話番号に電話してきてねと書いてあります。なので、メールに書かれている連絡先に電話をします。

すると...担当者がどうしましたかという感じで聞いてくるので、これまでの経緯を伝えます。 すると、問い合わせの過去ログを読み上げ始めました....いやいや、そういうのはいいから...と思って、待ってますから経緯を理解されてからでいいですよと伝えて、待ちます。

担当者が「お待たせしました。交換できないので、故障したPCをご返却させていただくことになります。申し訳ございません。」と言い出します。

ちょっとブチッときたので、「それは解っていまして、特に異論があるわけではありません。返却すると言われているPCが戻ってきていないので、状況を確認したいのです。」と言うと...「お待ちください」と言われます。

結構待たされて、言われたことは「確かにメールを出した日に故障したPCを返送するように工場には伝えている。ただし、工場から出荷されてはいないことは確認できている。」と言い出します。

.... .... .... は?

なんどかの会話を経て、ようやく「工場から出荷するとログが残るので、依頼はされているけれども、工場側が何らかの理由で出荷できていない」ということがわかりました。

当然、私は「なんで?」と聞くわけですが、なぜか「わかりません」と言ってきます。 「いや、工場に聞いて欲しいのですが」と食い下がると、「今日は答えられません」と言ってきます。

ちょっと、PC を人質に取られた気分になってきます。

確かにサポート窓口の時間があと数十分後に終わりそうだったので「では判明したら連絡してください。返却連絡いただいてから1週間ほどまっているので、早急に教えていただけますか?そして、なぜこんなに時間がかかっているのか、理解できるような理由を教えてください!」とお願いします (ちょっと怒ってます)。

担当者は「電話で連絡します」というので、「業務中かもしれないのメールでいいですよ」、と言って結果を待つことになりました。

しかし、翌日は待てど暮らせど連絡が来ません。ドウイウコッチャと思って、再度サポートに連絡すると、昨日とは別の方が対応してくれます。

対応番号を教えてくれというので、「知りません」というと調べてくれます。 どうやら、チャットの対応番号と電話の対応番号がわかれていて、チャットの担当番号だけでは経緯が不足しているので、電話の対応番号で問い合わせしてくれたほうがスムーズとのこと。まぁ、そっちのシステムの問題だとは思うけれど...と思いつつも、スムーズなほうがありがたいので、了解と伝えます。

この担当者の方はなかなかいい人で「うちの事情で申し訳ございません。実は、修理の返送手続きと同じ流れになるので、未修理の場合でも同じ流れで出荷されます。内部事情で申し訳ないのですが、この手続きが混雑しており、手続きが遅れているんです。」と教えてくれます。

「ただ返送処理すればええだけやん!」と思っていたわけですが、まぁそうもいえない事情のシステムなんですと申し訳なさそうに言われたら、どうにもなりません。いいでしょう、さらに待ちましょう、と思いました。

「で、いつ頃ご返送いただけそうでしょうか?」

が...耳を疑うような台詞を言われます。

「2 週間....」

....1 週間待って、さらに 2 週間!?エッ!?

と思って、「さすがにそれはひどくないですか?」と言いうと担当者が申し訳なさそうに工場に至急発送できないか調整してみすといってくれたので、待ちます。

なんと翌日の昼に「出荷した」と連絡がありました。

追加で 2 週間待ちかと思ったら、翌日発送で大変よかったです。

というわけで、翌日に Surface Book が戻ってきます。

そう、壊れたままで...。

米国 Surface サポートとの交換交渉

さぁ、いよいよ購入国である米国の Surface サポートに連絡です。 米国で、 "Hi! this one please" なんてひどい英語で購入するような人は泣いて逃げ出したい交渉が必要になることが必須ですが、さすがに音声だと勝ち目がなさそうだったので、日本と同じくチャットで質問します。 これなら、ヒアリングが苦手でもなんとかなると思ったからです。

日本のチャット システムとは少し違っていて、まずは BOT が対応してきます。 BOT というのは、会話ロボットのことで、決められた会話によってどんな支援が必要なのかを仕分けることをしてきます。

私が Surface Book の修理をしたいんだと言うと、BOT は "Surface Diagnostics Toolkit を試せ"、と言ってきます。

... なんだそれ?

と思いましたが、このツールをいれて診断しないと先には進めないようなので、素直にいれます。 ちなみにあとから解ったことですが、下記のサイトで日本語で説明があります。ようするに Surface 専用の簡単なトラブルシュート ツールです。

ハードウェア問題が確定なのに、こんなことに何の意味があるんだろう...と思いつつも、指示通りにタップやらキーボードの脱着などをしつつ、「問題なし」という画面を見ます。

...まぁ、問題はあるんだけどね。

と心でつぶやきつつ、ようやくサポート エンジニアと会話します。

「こんにちは。ご機嫌いかがですか?」

いかにもアメリカンな会話の始まり方で、「まぁまぁかな...」と答えると、「私があなたをハッピーにできるように支援しますよ!」とアメリカンな回答をされます。

日本でも伝えたように同じように伝えると...「キーボードを脱着してもらえますか」、「ハードウェアリセットを試してもらえますか」と続けて、「PC リフレッシュしてもらえますか?」と言ってきます。

... PC リフレッシュ!!!

どうして簡単にマシンのデータを全部消せと言うんだ...と思いますが、外付けキーボードで事象が直るんだし、UEFI画面でも事象再現するんだからリフレッシュしても意味ないよ!と言っても聞いてくれません。 仕方なく、PC リフレッシュします...当然事象は変わりません。

担当者が「ちょっとリソースを確認するから少し待ってくれ」と言うので、誰か別の担当者でも出てくるのかと思ったら、解決する方法を確認するということでした。待っていると...

「今度、アメリカにくるのはいつだい?」

と聞いてきます。

「いや、こないだ行ったからしばらく予定はないよ」

と言うと、「そうか...」といい、次に...

「ほかの国に行く予定とかは?」

と言い出します。どうも嫌な予感がこのあたりからしてきます...。

「ない」と答えると...なんと、来てくれないと交換できないと言われます。

修理にまたアメリカに来いだとっ!?

若干推測ですが、おそらく米国キーボードな Surface Book を扱っている国なら交換してくれるのでしょう。残念ながらそんな予定はないので、交換する方法がありません。「そっちに郵送で送るのは駄目?」というと、そういうやり方はサポートしていないと言われます。

しばらく不幸なやりとりをした後で、「他のオプションがあるとすれば、友人や家族が海外にくるときに代行を依頼することだね」と言いだします。まぁ、本人である必要は無い、というのは 1 つの収穫です。

もし、友達や家族の旅行予定がないから交換は自分でやるしかないです。ホノルル (ハワイ) とかが飛行機+ホテル込みで HIS の割引プランなら 10 万ぐらいですよ、とだけ伝えておきます (私も最後までこの手段にするか悩みました...)。

私の場合は米国に同僚がいたので、同僚にお願いして代行を依頼しました (次回、日本帰国時におごるというわかりやすいトレードで)。これだけでも、皆様からしたら "ミラクルな手段" なのかもしれません。

サポート担当者に代行をお願いするというと、以下を Surface Book 本体と一緒に持参しろと言ってきます。

  • 購入時のレシート
  • このサポート対応のケース番号

日本だと本体を送るだけですが、レシートもいるんだそうです。ちなみに、交換時には別途 Surface をデバイス登録するメールアドレスも聞かれます。答えられないと、交換処理を受け付けてもらえないのでご注意を。

さて、あとはデバイスを送るだけです。 もっとも簡単に早く送るには EMS と呼ばれる郵便局が提供している国際スピード郵便というのがいいです。本体の送付だけでも 6000 円ぐらいして、さらに保証をつけると 7000 円に迫る勢いな値段になりますが、 3 日程度でアメリカの方に届きました。

Surface Book の交換

話でいうならば、クライマックスぐらいのところな気分ですが...ここは代行をお願いしているので、あまり話はありません。

予定通り 3 日ほどで届き、同僚の機転ですぐに受け取り後に交換処理をしてもらい、あっさり交換してもらえました。

本体しか送っていないのですが、なぜか箱ごと新品をもらったようです (むしろ、日本と同じようにちゃんと検品した商品を送付してくれたほうが再故障の不安がなくていいような気もしますが...)。

返送の方法で同僚と調べてみると、いわゆる宅配便に相当する Fedex や UPS は送料が 2 万円ぐらいすることがわかりました。Surface Book の重さや価格などが理由なのでしょう。

結局、USPS と言われるアメリカの郵便局で送ってもらいます。"Priority Mail Express" と呼ばれる日本の EMS のような方法で送付してもらうのが一番早くて安いことがわかり、それでお願いします。 値段は配送中の故障時の保証をつけて、1万円弱といったところです。日本よりも高くて、びびります (どうも日本がとても安いようです)。

待てど暮らせど進まない "輸入申告手続き中" という状態

同僚に何日ぐらいに届くの?と聞くと、「1 週間ぐらい」と言われます。

日本から海外にいくのに 3 日なのに、1 週間とは長い!と思いましたが、まぁそれ以上早くすると送料が 2 倍以上しますから気にしません。なにせこっちは、PC が 1 週間返却されなくても待ち続けた男ですからね!

送付してもらってからは、毎日のように EMS の番号でトラッキングします。

すると、順調に 2 -3 日で日本に到着したのを確認して、「予定よりも早く届くかな?」とワクワクしていると、「輸入申告手続き中」という状態で 3 日ほど進みません...。

これまでの流れから、「コイツ、国際郵便初めてだな?」と思ったかも知れませんね。お察しの通り、初めてです。

というわけで、きっと国際郵便をやった方ならわかるであろう最後の砦...「税関」処理がやってきます。

そもそもすべての国際郵便物は税関処理の対象です。海外旅行から戻ってくると申請書として白い紙を書くと思いますが、荷物だけの場合でも例外ではないのです。 このとき、20 万円を超えると、なんと別途申請が必要となります (超えなくても輸入品によっては当然関税がかかりますよ)。今回の場合、日本円にして 28 万円ぐらいの商品なので、当然のように対象です。

が...この仕組みがアナログです。

20 万円を超える商品だと税関が判断すると、郵便局から書類が "速達" で送ってきます。

...速達!

久しぶりに聞きました (昔、郵便局でアルバイトをしてました)。 書類にはこの処理を郵便局に代行するか、自分でするか、それとも他に依頼するかを選ぶようになっており、郵便局側に依頼するなら代行依頼書を書くようになっています。もちろん、こっちの返送も速達です。

書類を読むと、20 万円を超える商品の場合は課税が発生する、代行処理には別途費用がかかるとあります。 代行費用はだいたい 6000 円ぐらいで、これが別途かかるということのようです。

「そもそも今回の場合は、故障して交換したわけだし、購入したものじゃないのだから対象じゃないでしょ!」と思いましたが、こんな書類がきているので、素直に税関に聞くと、驚くべき回答がやってきます。

「課税対象です。」

そんなの知らんがな!と思いましたが、故障で海外で輸出と輸入をする場合は、申請書を出しておくと、輸入時の会税対象から外せる仕組みがあるそうです。ただし、これは事前に輸出時に申請を出しておく必要があり、その場合は同一のマシンである必要があるとのこと。さすが、日本。システムがわかりにくい。

ただ、この話を聞いてわかった方もいると思いますが、ようするに同じマシンでなければ対象になるのです。今回の場合、修理といいつつも実際に行われているのはマシンの交換なので輸出時と輸入時のマシンは異なります。このような場合は、新しいデバイスが日本に来たので、輸入時に課税対象になるようです。つまるところ、申請していようがしていまいが、Surface Book の場合は代替機を輸入した時点で課税対象になるのです。残念。

「そんなこと言ったら、受け取ったマシンが壊れてたら無限に税金払うことになるじゃないの?」と半分ムカムカしながら話すと...「そうです」と言われてしまい愕然。日本の税法の仕組みはどうかしてます。

ただ、いいことも教えてもらいます。 個人利用用途だという書面を書けば、60% が課税対象になるというのです。 もちろん個人用途なのですが、言わないと個人用途と見なさないよとは知らなかった...。

そして、60% が課税対象になるので、ぎりぎり 20 万円の課税対象から外れて、代行処理の費用も支払わなくて済むことが確定します。

おぉ、結局支払わなくていいの!?と思った、アナタ。..残念。

消費税 (課税対象の 8%) は支払いが必要です。実際の課税額は税関が決めるので、ケース バイ ケースになるようですが、私の場合は 1 万円ちょっとを追加支払いすることになりました。

あれよあれよという間に、3 万円ぐらいかかってガッカリですが、こうしてようやく私の新しい Surface Book が届きます。 配達時に税関での処理のお金を支払うので、金額の支払いをして商品を受け取ります。いい出費です。

エピローグ (まとめ)

私がこの物語で特に言いたいことは、海外で Surface Book 買おうかななんて思っている人は絶対にやめておけ!ということです。 とはいっても、こんな顛末になるとは知らないで購入してしまって、このサイトを見る人もいるでしょう。その場合には、ぜひ交換は英語で交渉する必要があり、実際の交換は米国で行わないといけない、そしてもし知人が米国にいて代わりに手続きしてくれたといしても 3 - 4 万円ぐらいかかるよ!という事実を共有できればと思います。

まぁ正直、次にもう一回壊れたら、ワイキキ ビーチでのんびりしつつ、3 泊 4 日の旅行を楽しみつつ交換処理したほうが、トータル 10 万円程度で済んでお得なんじゃないかな?とも思いつつあります。

壊れたら、マイクロソフトが嫌いになると思いますけどね!(笑)

今の Surface Book 2 が故障しないことを祈りつつ、この記事を Surface Book 2で書き上げてインターネットの世界に公開します。

それでは、またどこかでお会いしましょう。

いまどきの Vagrant (VMWare Workstation) で Windows の Box を作る方法

Vagrant の場合、Linux などの仮想マシンは簡単に入手できるはずです。

しかし、ライセンス問題がある Windows の仮想マシンはほとんど存在しません (人気が無いのかもしれませんが...)。 そこで、Windows の Box の作成方法を示します。

VM の作成

VM の設定

ディスクは [仮想ディスクを複数のファイルに分割] を選択します (既定)。

メモリは Vagrant の資料には 512MB と書かれていますが、Windows の場合はパフォーマンスの観点から 1 GB or 2GB が良いと思います。

Windows (OS) のインストール

普通に VMWare Workstation を使用して OS をインストールするだけです。

インストール完了後、ログインするユーザーとして次を設定します (Windows Server など、複雑なパスワードにしなくてはいけない場合は、一時的に別のパスワードに設定します)。

ユーザー名: vagrant パスワード: vagrant パスワードのヒント : パスワード以外の文字列

VMWare Tools のインストール

VMWare Tools をインストールします。通常のインストール方法と同じです。

インストール後、コンピューターを再起動します。

設定の変更

次の設定を変更する必要があります。

  1. UAC の無効化
  2. 複雑なパスワードの無効化
  3. シャットダウンの記録の無効化
  4. "サーバー マネージャーをログイン時に起動する"の無効化

UAC については、Windows 8/8.1 以降の環境では下記のレジストリで無効化する必要があります (バーを下げるだけでは UAC が無効にならないため)。 注意 : 管理者権限でコマンドプロンプトを起動する必要があります。

reg add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /d 0 /t REG_DWORD /f /reg:64

WinRMの構成

管理者権限でコマンドプロンプトを開き、次のコマンドを実行します。

winrm quickconfig -q
winrm set winrm/config/winrs @{MaxMemoryPerShellMB="512"}
winrm set winrm/config @{MaxTimeoutms="1800000"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
winrm set winrm/config/service/auth @{Basic="true"}
sc config WinRM start= auto

なお、接続しているネットワークのタイプがパブリックの場合は quickconfig 時にエラーになるので事前にパブリック以外 (プライベート or ドメイン) に変更してください。

また、WinRM 1.1 (Windows Server 2008) 以前の場合は下記のコマンドも追加で必要。 ただし、Windows Server 2008R2, Windows 7 以降は不要です。

netsh firewall add portopening TCP 5985 "Port 5985"
winrm set winrm/config/listener?Address=*+Transport=HTTP @{Port="5985"}

リモート デスクトップの設定

RDP 接続したい場合は、システムのプロパティを開き、リモート接続を許可するように設定を変更してください。 また、念のためファイア ウォール設定で RDP のポートを開けておきます。

その他

Windows Update 、アプリケーションのインストールなどを行います。

マシンのシャットダウン

すべての作業を終了後、VM をシャットダウンさせます。

shutdown /s /t 0 /f

パッケージング (BOX 化)

仮想マシンを作成したフォルダに移動し、下記の作業を行います。

内容物の確認

NVRAM, VMSD, VMX, VMXF, VMDK ファイルが存在することを確認します。 それ以外のファイルは削除してしまって構いません。

ディスクの最適化

なるべく BOX のサイズを小さくするためにデフラグ (-d) とシュリンク (-k) を次の手順で最適化します。 なお、ディスクを分割している場合は、メインの仮想ディスク (-snnn が付与されていないもの) に対して実行します。

"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -d <main.vmdk> 
"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -k <main.vmdk>

metadata.json ファイルの作成

BOX FILE FORMAT に従って、metadata.json を用意します。 Windows 10 1607 のファイルを作成した例を示します。公式のものには、checksum などアップデートするための設定などが書かれていますが、動かすためには provider の設定があればいいだけです。

{
  "name": "en_win10_1607_x86",
  "description": "This box contains Windows 10 Pro 1607 (x86) English.",
  "provider": "vmware_desktop"
}

Vagrantfile ファイルの作成

下記のような Vagrantfile を用意します。特に guest と communicator が重要で、これが正しくないと起動もしません。

# -*- mode: ruby -*-
# vi: set ft=ruby :
 
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.

Vagrant.configure("2") do |config|
  config.vm.guest = :windows
  config.vm.define "vagrant-windows-10"
  config.vm.box = "windows_10"
  config.vm.communicator = "winrm"

  # Admin user name and password
  config.winrm.username = "vagrant"
  config.winrm.password = "vagrant"

  config.windows.halt_timeout = 15

  config.vm.network :forwarded_port, guest: 3389, host: 3389, id: "rdp", auto_correct: true
  config.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", auto_correct: true
  config.vm.network :forwarded_port, guest: 5985, host: 5985, id: "winrm", auto_correct: true

  config.vm.provider :vmware_workstation do |v, override|
    #v.gui = true
    v.vmx["memsize"] = "2048"
    v.vmx["numvcpus"] = "2"
    v.vmx["ethernet0.virtualDev"] = "vmxnet3"
    v.vmx["RemoteDisplay.vnc.enabled"] = "false"
    v.vmx["RemoteDisplay.vnc.port"] = "5900"
    v.vmx["scsi0.virtualDev"] = "lsisas1068"
  end
end

パッキング

残念ながら、vagrant package コマンドは VirtualBox 専用なので、GZIP などの形式に圧縮します。

私は、公式のサイト通り、tar コマンドを使用して圧縮しています。

cd "E:\Virtual Machines\en_windows_10_1607_x86_vmware"
tar cvzf my.box ./*

Windows に tar コマンドは普通存在しないので、GitHub Desktop などを導入して、Linux のコマンドを呼び出すのが簡単です。ZIP でも問題ないので、そこまでするかどうかは好みの問題です (私は圧縮効率で選択)。

テスト

よい子はテストしましょう。

vagrant box add <box name> <box path>
vagrant init <box name>
vagrant up --debug

参考情報

Selenium を使って Microsoft Edge の UI テストをする

はじめに

Selenium は Firefox との相性がとても良い。WebDriver のインストールは不要、テストもなるべく失敗しようなような動きをしてくれる。 だが、ほかのブラウザーではそうはいかない。そこで、今回は Microsoft Edge におけるテストについて説明する。

Selenium を使うためにインストールが必要な NuGet パッケージ

Visual Studio の好きな言語で単体テストのプロジェクトを作成し、次の NuGet パッケージをインストールすればよい。

  • Selenium.Support
  • Selenium.WebDriver

Microsoft Edge Web Driver のインストール

Microsoft Edge Web Driver は下記からダウンロードできる。

注意してほしいのは、使用されている Windows 10 のバージョンによってインストールするドライバーが違うということだ。 自分自身が使っているバージョンをしっかり確認したほうがいい。

コード記述例

後は下記のようなテストを書くだけだ。 下記のテストは、amazon.co.jp に移動し、いくつかの検索条件で検索したあと、その画面をキャプチャするものである。 テキストの入力、ボタンのクリック、検索後の遅延待ちや、画面取得というのはよくある話なので、その辺を理解するのに役に立つと思う。

using System;
using System.Drawing.Imaging;
using System.IO;
using System.Threading;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using OpenQA.Selenium;
using OpenQA.Selenium.Edge;
using OpenQA.Selenium.Firefox;
using OpenQA.Selenium.Interactions;
using OpenQA.Selenium.Remote;
using OpenQA.Selenium.Support.Extensions;
using OpenQA.Selenium.Support.UI;

namespace SeleniumTests
{
    public static class WebDriverExtensions
    {
        public static void SaveScreenshot(this IWebDriver driver, string fileName, ImageFormat format)
        {
            Screenshot screenshot = driver.TakeScreenshot();
            screenshot.SaveAsFile(fileName, format);
        }
    }

    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void AmazonSearchTest()
        {
            RemoteWebDriver driver = null;
            try
            {
                var list = new[] { "Visual Studio", "Windows 10", "ビール", "少年ジャンプ" };

                string serverPath = "Microsoft Web Driver";
                serverPath = Path.Combine(Environment.ExpandEnvironmentVariables(Environment.Is64BitOperatingSystem ? "%ProgramFiles(x86)%" : "%ProgramFiles%"), serverPath);
                EdgeOptions options = new EdgeOptions { PageLoadStrategy = EdgePageLoadStrategy.Normal };
                driver = new EdgeDriver(serverPath, options);

                // 暗黙的待機 (要素を検索するときに、見つけられるまで指定時間分だけ待つ)
                driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(5));

                foreach (var keyword in list)
                {
                    driver.Url = "http://www.amazon.co.jp";

                    // 本当はこれで検索ボックスに文字列を入力できるが...
                    //IWebElement element = driver.FindElement(By.Name("field-keywords"));
                    //element.SendKeys(keyword);

                    // Edge は 日本語 を SendKeys すると Unknown Error になるので、ExecuteScript で回避
                    driver.ExecuteScript($"document.getElementsByName('field-keywords')[0].value = \"{keyword}\"");

                    // 検索ボタンをクリック
                    IWebElement element2 = driver.FindElementByClassName("nav-input");
                    element2.Submit();

                    // 検索結果のページが読み込み完了するまで待機する
                    WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(20));
                    wait.Until(_ => driver.ExecuteScript("return document.readyState").Equals("complete"));

                    // 画面ショットを取る
                    driver.SaveScreenshot($"{keyword}.png", ImageFormat.Png);
                }
            }
            finally
            {
                driver?.Quit();
            }
        }
    }
}

テストのコツ

実際に動かしてみるとわかるが、Microsoft Edge の Web Driver は、Edge が起動していると一度すべて閉じてしまう。なので、インターネットで調べ物をしながらコードを書いているなら Microsoft Edge を使わない方がいい。 また、Edge を起動したままにしていると、どうもテストの失敗率が高くなるので、テスト前には Microsoft Edge 自体を落としておくほうがよい。

Edge が起動しなくなったときの対処

上記のコードにも Try-finally で EdgeDriver.Quite() を呼び出しているが、このメソッドがちゃんと呼び出されないと次回以降の起動ができなくなることがよくある。 ただ、上記コードを書いていても、デバッグなどで途中停止したりすると同じ現象になることがある。 その場合はコンピューターを再起動する、または sihost.exe (Shell Infrastructure Host) を Kill するとよい (当然、自己責任で)。