読者です 読者をやめる 読者になる 読者になる

Google Wifi でメッシュ構築してみた

ハードウェア

先日の記事:

espresso3389.hatenablog.com

ですが、このような、製品名も間違っている上に、最大の関心事である、メッシュ構築をしてないとは何事だという感じのツイートを頂きました。(※IEEE 802.11s とは、メッシュネットワークの規格です)

仰るとおりです。 なので、狭い我が家で、ぶっちゃけ、全然、メッシュネットワークの恩恵を受けられないとは思いますが、とりあえず、2台運用してみました。

リビングルームから遠い、風呂場の脱衣所的な所にもう1台を設置してみました。

f:id:espresso3389:20161229030757p:plain

この手順が、結構謎というか、実のところ、1台目もそうだったんですが、まぁ、自動認識はうまく行きません。Bluetoothで近くのAPを探しているはずなのですが、ダメです。なので、結局は、QRコードを撮影してペアリングしました。

f:id:espresso3389:20161229031012p:plain

f:id:espresso3389:20161229031027p:plain

この後、30秒ぐらいで完了し、次の画面が表示されます。ただし、ファームウェアのアップデートがあると5分前後かかるみたいです。

f:id:espresso3389:20161229031202p:plain

見た目の変化

正直、面白いものは何もありません。2台になり、そして、それなりの電波強度が確保できていることが確認できるぐらいです。

f:id:espresso3389:20161229033242p:plain

f:id:espresso3389:20161229031306p:plain

結論

うーん、何にも変化が分かりませんね。記事としても何にも面白くない結果に終わりました。

で、実は個人的にはとっても気になっていることが一つだけあるんです。それは amazon.com での Q&A にあるんですが、

www.amazon.com

ここに、Kate P さん(おそらく Google の人)のコメントとして、

In our tests, we've found it can handle up to 200 devices at once; 100 per radio band. You could potentially use Google Wifi in a cafe, especially since you can create a separate guest network. Cafe customers can use the guest network without having access to devices on the main network.

なんてことが事も無げに書かれているんです。超絶意訳すると、

「我々のテストでは、同時に200台のデバイスを裁くことが出来た(バンド毎に100台)。ゲストネットワークを使って Google Wifi をカフェで利用することも可能ではあるだろう。カフェの客はゲストネットワークでメインネットワークにアクセスできない状態で利用することが出来る。」

it がワンセットなのか、1台なのか判断が出来ないところではあるんですが、いずれにしても本当かよ?って思う数のデバイスです。で、自宅とかじゃなく、カフェとかでも多分使えるとか書いちゃってる。

台数が増えて不安定になりがちな会社ネットワークとかには打って付けかもしれません。これに関しては、会社に残りの2台を持って行ってテストするとか、そういう実験が必要かもしれません。

Google Wifi を入手した

ハードウェア

※2016-12-28 製品名が違うという致命的な問題wを指摘されましたので修正しました。 Google Wi-Fi -> Google Wifi

f:id:espresso3389:20161227161804j:plain

今更、Wi-Fi ルーターなんて買ってどうするんだよ?って人もいるかもしれませんが、この秋ぐらいから発表されている Wi-Fi ルーターには、複数台のWi-Fi AP間で協調して動作する、いわゆるメッシュネットワーク機能などと言われる機能が搭載されているモノが多くなってきています。

従来の中継器を利用して電波の届く範囲を広げるものと比べると、電波の範囲を協調的に調整できることや、Wi-Fi を利用しているデバイスが、複数AP間をまたがって移動しても接続を維持できる(逆に従来の仕組みでは一度、ネットワークが切断されていたので、動画などを再生しながら移動すると途中で切れていた)などの特徴が有るのです。

まぁ、複数AP間をまたがって移動しても接続が切れないなんていうことがクリティカルになるような使い方をする人はほとんどいないとは思いますが、Wi-Fiの電波が悪すぎて、ネットが遅い、繫がらないなんていう人はかなりいるので、前者の機能が魅力的に映る人は多く居るでしょう。

すでに日本で購入できるものとしては、Orbi WiFi Systems | Networking | Home | NETGEARがあります。

Amazon CAPTCHA

この製品は、2台のWi-Fi AP間を専用の周波数帯を利用する専用プロトコルで接続しており、Wi-Fi そのものの電波とは干渉しないために、AP間での通信で全体の通信速度が低下しないことが特徴のようです。また、この製品は、2台が同梱されたパッケージですが、この2台には明確に親機、子機の区別があります。実売、45,800円程度の様です。実は、しばらく前までは、Amazonではキャンペーンで5,000円引きだったのですが・・・。

Google Wifi

さて、今回入手したのは、NETGEAR Orbi ではなく、Google Wifiです。 こちらは、名前の通り、Google が発表した新しい Wi-Fi ルーターです。

madeby.google.com

まだ、日本では発表されていません。米国では、1台 $129、3台パックで、$299で売られています。 で、3台パックを個人輸入しました。とはいえ、Amazon.comでさっくりと購入できたので、ハードルはかなり低かったです。

https://www.amazon.com/gp/product/B01MAW2294/

で、送料と通関手数料などで$40弱はとられます。

Item(s) Subtotal: $299.00
Shipping & Handling: $13.79
Total before tax: $312.79
Estimated tax to be collected: $0.00
Import Fees Deposit $25.02
Grand Total: $337.81

ただ、トランプさん当選後、ドルがどんどん高くなったせいで、結果的には、クレジットカードの明細上では、40,668円(120.38円/$)という金額になりました。予約したときからするとレートが7円ぐらい動いています。とはいえ、まぁ、3台でこの価格だったら文句はないでしょう。

※所謂、技適というものは通過しておりません。輸入をするのも、それを利用するのも自己責(略

パッケージ、ACアダプターなど

箱はそれなりの高級感はあります。で、開けた直後がこんな感じ。およそ、Wi-Fiルーターには見えません。

f:id:espresso3389:20161227162538j:plain

本体と、極太きしめんLANケーブル、そしてACアダプターが3つずつ入っていました。 本体と、ACアダプターが3つずつ、極太きしめんLANケーブルが1個入っていました。(ちゃんと箱の中を確認していませんでした・・・) ACアダプターは、USB-Cで、5V、3Aのものでした。

f:id:espresso3389:20161227163155j:plain

f:id:espresso3389:20161227163251j:plain

そして、うちの窓際で動作している時の絵です。 見た目がシンプルでおとなしいので、リビングの隅に置いても家の人にとやかく言われるような見た目ではありません。

f:id:espresso3389:20161227175134j:plain

仕様

調べれば分かることではありますが、箱の裏の内容を転載します。 目立つところでは、メッシュ機能、TXビームフォーミング、Bluetooth Smartと、自動更新。で、TPMってファームウェアの乗っ取り防止とかですかね?

設定

さてさて、実際の設定ですが、これには、Google Wifi というそのままの名前のアプリを利用します。Android用、iOS用がリリースされています。そして、幸いなことに、現状でも、日本からでもダウンロードできます。

このアプリは、Google Wifiルーターに対しては、Bluetooth(なので、箱にはBluetooth Smart Readyと書いてある)で接続を行います。そのため、ルーターの設定をブラウザから設定していて、設定を間違って途中で設定を修正できなくなると言う良くある問題が有りません。いろんな設定を試す人には便利だとも言えます。

f:id:espresso3389:20161228041556p:plain

見た目も設定もシンプルです。なので、最近の機能てんこ盛りルーターを見慣れていると、何にも出来ないように感じる人もいるでしょう。設定は、基本的な DNS(自動/プロバイダ/カスタム)、WAN IP(DHCP/固定/PPPoE)、LAN IP/DHCPとポートフォワード、UPnP、動作モード程度ですが、DHCPMACアドレスに対してIPを固定する際やポートフォワードなどは、デバイス名を見ながら設定できるなど、意外と気が利いています。

f:id:espresso3389:20161228042029p:plain

ブリッジモードは微妙

また、動作モードを、NATかブリッジから選択できることは出来るのですが、ブリッジで動作させると無効になって当然の機能(DHCPとかポートフォワード,UPnP)ももちろんありますが、ゲスト用Wi-Fiが動かなくなったり、電波制御(Wave control)なるものが動かなくなったりと、割と悲しい状態になります。 どうやら、このWi-Fiルーターは、NATとして動作させることを前提に作られていることは理解しておいた方が良いでしょう。

f:id:espresso3389:20161228053036p:plain

なので、いわゆるホームゲートウェイが必須になる接続方式(auひかりとか)だと、いわゆるdouble-NATという、分からない人にはどうでも良いけど、物事が理解できる人には微妙に嬉しくない状況になることは理解しておく必要があります。

まぁ、実のところ、僕は、まさしく、そのauひかりなので、普通にホームゲートウェイに対してGoogle Wi-Fiを接続するとdouble-NATになります。なので、Google Wi-FiDMZに置くという方法で回避しました(詳しくはググってください。直ぐに出てきます)。

ネットワークチェック(Network check)

ネットワークチェックでは、Googleのサーバーに対して、ダウンロード、アップロードの速度を計測できます。

f:id:espresso3389:20161228043152p:plain

プライオリティデバイス(Priority device)

一時的に帯域を確保しておきたいデバイスのために、デバイスにプライオリティを設定できます・・・って恒久的にって訳じゃないので、どうも、一時的にストリーミング配信をするだとか、映画を観るだとか、そういうシチュエーションに使うんでしょうか。個人的にはあんまり使うメリットが見えません。

f:id:espresso3389:20161228043507p:plain

パスワード表示 (show Password)

ゲストの人にパスワードを教えたりする場合にパスワードを表示したり、あるいは、共有機能で、LINEとか何やかんやに送ったり出来ます。まぁ、順当なところでしょう。

その他の機能 (More actions)

未評価。

ゲスト Wi-Fi/ファミリー Wi-Fi

ゲスト機能は、一部のデバイスにのみアクセスできるゲスト用のWi-Fiですね。 ファミリーWi-Fiの方は、夜中には子供にWi-Fi使わせないとか、そういう意地悪が出来るようです。僕には子供はまだ居ませんので使ってません。

ホームコントロール(Home control)

Googlecast 系のデバイスや AppleTV がごにょごにょって感じみたいですがよく分かりません。未評価。

ネットワーク管理機能

f:id:espresso3389:20161228045124p:plain

ネットワークのトポロジや、デバイス一覧、そして、デバイス毎の通信量、その履歴などが見れます。 また、デバイスには、自分で好きな名前を付けられますので、初期状態で、Android Deviceなんていう名前が並んでいてもどうにかなります。PC/Mac/iOSに関しては、名前はちゃんと出てきますが、Mac/iOSでは日本語で名前が付いていても、ローマ字表記で出てくるので、気持ちなと思う人は名前を変更すべきでしょう。

f:id:espresso3389:20161228045145p:plain

f:id:espresso3389:20161228045213p:plain

f:id:espresso3389:20161228045224p:plain

リモートからの管理

で、この管理アプリ、Googleのアカウントに関連付けられるので、自宅に居なくても自宅の状況を確認できるようになっています。つまり、僕の様に遠隔地に両親が住んでいて、その両親の使うネットワークの管理をリモートからやらないといけないみたいな境遇の人々には大きなメリットとなる可能性があります。というか使ってみて気づきました。

で、メッシュ機能は?

まだ試していません。 というのも、今まで、NEC Atermを使ってたんですが、マンションなので、Wi-Fi強度の軍拡競争が激化しており、ルーター付近以外では電波が極端に弱くなったり、不安定になったりしていたのですが、Google Wifiを導入したら、一気に自宅全体が快適に通信できるようになってしまったのです(うちは、70平米程度)。

そもそも、Google Wi-Fi、よく見ると、Wi-Fiのチャネルを設定する機能はおろか、よく見れば、2.4GHz、5GHzを選択するところすらないのです。デバイス接続時に勝手にどちらかが振り分けられているように見えます。これ、ひょっとして、バンド間のハンドオーバーもイケるんですかね?よく分かりませんが。

つまりですね、「人間はどの電波帯域を使ってるとか、混線とか気にすんな。俺が全部勝手にやる」っていうスタンスなんですね。 同じ理屈でというか、Google様らしく、ファームウェアのアップデートもデフォルトで自動。 人間様は、Wi-Fiが使えるという事を enjoy すればそれで良いというそういう割り切りWi-Fiルーターなんですね。そう考えると、ブリッジなんて言う物騒なモードがないのも納得がいかないわけではありません。

結論

VPN欲しいとか、ストレージ機能欲しいとか、そういう欲張りなことを言わない人ならば、安定したWi-Fiがほぼ全自動で手に入る素晴らしいデバイスです。少なくとも僕はもう自宅ネットワーク管理者は疲れたので本当に便利だなぁと感じています。

また、3台セットを買ったのに、結局1台しか使っていませんが、リモート管理などを考えると、これ、1台は実家に持って帰れば良いんじゃ無いかなとか思っているところです。

VSCode で Electron のアプリをデバッグするときの launch.json runtimeExecutable について

Visual Studio Code Electron

分かったら一瞬だけど、分からないとずっと悩む奴です。

Electron を実行しようとすると、macOSLinuxだと、

node_modules/.bin/electron

を実行すれば良いのですが、 Windows では、

node_modules/.bin/electron.cmd

を実行しなければなりません。そのため、 .vscode/launch.json を下記のように設定すると、 Windows ではデバッグできません。

// この launch.json では Windows ではデバッグが出来ません!
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch",
      "type": "node",
      "request": "launch",
      "cwd": "${workspaceRoot}",
      "program": "${workspaceRoot}/app/index.js",
      "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
      "runtimeArgs": [
        "--enable-logging"
      ],
      "args": [
        "."
      ]
    }
  ]
}

console によるターミナル設定

実は、 launch.json には、 console というパラメータがあり、それによって、実行ファイル(runtimeExecutable)をどうやって実行するかを選択することが出来ます。この値が、既定では、internalConsoleになっているようです。

そして、その場合、Windowsでは、node_modules/.bin/electron がそのまま実行されることになるのですが、このファイルはシェルスクリプトなので、Windows では実行できず、実行に失敗します。

そこで、 consoleの設定を、integratedTerminal もしくは、 externalTerminal に設定すると、「デバッグ」はうまく動くようになります。

どうしてこのような違いが起きるのかというと、 integratedTerminal もしくは、 externalTerminal に設定すると、内部的に、 cmd.exe を挟んで起動されるために、 electron というファイルではなく、Windows で実行可能な、 electron.exeelectron.cmd を探してくれるようになるからです。

ただし、externalTerminal にすると、デバッグ終了時に、無駄に開いたコマンドウィンドウを閉じないといけない羽目になって、面倒なので、 integratedTerminal を指定する方が良さげです。

従って、launch.json は次のように書くべきでしょう:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch",
      "type": "node",
      "request": "launch",
      "cwd": "${workspaceRoot}",
      "program": "${workspaceRoot}/app/index.js",
      "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
      "runtimeArgs": [
        "--enable-logging"
      ],
      "args": [
        "."
      ],
      "console":"integratedTerminal"
    }
  ]
}

プラットフォーム毎の固有設定

また、意外と言及されてないのは、launch.jsonには、 windowsosxlinux といったトップレベル要素が用意されており、パラメータを環境毎に切り替えられるようになっていると言うことです。なので、書こうと思えば、次の例のように、Windows 用の実行ファイルを別に設定することが可能です。

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "node",
            "request": "launch",
            "cwd": "${workspaceRoot}",
            "program": "${workspaceRoot}/app/index.js",
            "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
            "runtimeArgs": [
                "--enable-logging"
            ],
            "args": [
                "."
            ],
            "windows": {
                "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd"
            },
            "console":"integratedTerminal"
        }
    ]
}

ThinkPad 英語配列を購入したらキーボードが日本語配列として認識されている!

thinkpad

ThinkPad は、昔からそうなんですが、日本で英語配列を購入すると、キーボードが日本語配列として認識されていて、最初から死にそうになります。

この状態だと、 \ を入力こともできなかったりと、実はいろんなソフトウェアをセットアップするだけでも辛い思いをします。

でも、キーボードをどうやったら英語配列として認識させることが出来るんだろう?っていう話になると、大体は、キーボードのドライバーを・・・って話になるんですが、もっと簡単な方法があります。

それは、レジストリのパッチを適用するってことだけです。下記のページにある、 kbd-enus.reg をダウンロードして、適用してく、マシンを再起動してください。それだけで配列が英語配列になります。

https://onedrive.live.com/?id=D5AF8D00E0A19C13%2193605&cid=D5AF8D00E0A19C13

逆に、日本語配列に戻したいときは、 kbd-japanese.reg を適用して再起動するだけです。

内容は、見れば分かりますが、

kbd-enus.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
"LayerDriver JPN"="kbd101.dll"
"OverrideKeyboardIdentifier"="PCAT_101KEY"
"OverrideKeyboardType"=dword:00000007
"OverrideKeyboardSubtype"=dword:00000000

kbd-japanese.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
"LayerDriver JPN"="kbd106.dll"
"OverrideKeyboardIdentifier"="PCAT_106KEY"
"OverrideKeyboardType"=dword:00000007
"OverrideKeyboardSubtype"=dword:00000002

僕はこのファイルを Dropbox に置いているので、マシン新調後は、このファイルをダブルクリックで適用しています。

いや、今日、飲んでて、英語配列の人達はどうやって \ 入力してるの?って聞かれたのでこの記事を書きました。

VSCode のコマンドラインについてちょっとだけ書く

はじめに

これは Visual Studio Code Advent Calendar 2016の9日目の記事です。

VSCode について何か書こうと、自分に使命を課すように、アドベントカレンダーに登録したものの、実際には何について書こうと悩んだあげく、ヌルい内容になってるかもしれませんが(だって、今 12/8 22:00なんだもん、さすがに何か書かないと!)、温かい目で読んで頂けるとありがたいです。

VSCode のコマンドライン

VSCode をインストールすると、 code というコマンドがインストールされ、さらに既定ではパスも通されることは、インストーラを見ていれば分かると思いますが、 code コマンドをどこまで使いこなしているでしょうか?

code コマンド

Windows だと、 C:\Program Files (x86)\Microsoft VS Code\bin には、 code.cmd と、 cmd というファイルが存在しています。

f:id:espresso3389:20161208222142p:plain

普通に、いろんな所から code って叩いて起動するのは、当然、 code.cmd なんですが、 code とは? ってなりますよね。で、これは、本来、 node とか npm 系の文化なんでしょうけど、 Cygwin もちゃんとサポートするぜ的な感じでシェルスクリプトが提供されてるんですね。 とはいうものの、実は、 Windows 10 Insider Preview Build 14951 以降の WSL (Bash on Windows) だと、 code ってコマンドを打つと、こっちのシェルスクリプトが実行されて、 VSCode が起動します・・・が、残念ながらパスの解析ができないので、カレントディレクトリのファイルをファイル名だけで指定した場合以外はファイルを開くことは出来ません。 さらに、cli.js というファイルを新規で開いてしまいます。

さて、とりあえず、 --help の内容でも見てみましょう。

Visual Studio Code 1.7.2

Usage: code.exe [options] [paths...]

Options:
  -d, --diff                  Open a diff editor. Requires to pass two file
                              paths as arguments.
  -g, --goto                  Open the file at path at the line and column (add
                              :line[:column] to path).
  --locale <locale>           The locale to use (e.g. en-US or zh-TW).
  -n, --new-window            Force a new instance of Code.
  -p, --performance           Start with the 'Developer: Startup Performance'
                              command enabled.
  -r, --reuse-window          Force opening a file or folder in the last active
                              window.
  --user-data-dir <dir>       Specifies the directory that user data is kept
                              in, useful when running as root.
  --verbose                   Print verbose output (implies --wait).
  -w, --wait                  Wait for the window to be closed before
                              returning.
  --extensionHomePath         Set the root path for extensions.
  --list-extensions           List the installed extensions.
  --show-versions             Show versions of installed extensions, when using
                              --list-extension.
  --install-extension <ext>   Installs an extension.
  --uninstall-extension <ext> Uninstalls an extension.
  --disable-extensions        Disable all installed extensions.
  --disable-gpu               Disable GPU hardware acceleration.
  -v, --version               Print version.
  -h, --help                  Print usage.

このコマンドラインのオプションについては、1.8.0 系(VSCode Insiders)でも、--extensionHomePath--extensions-dir に変わっているだけで、特に変更はないようです。

code --diff

code に引数として、ファイル名を渡して開くというのを除けば、もっとも利用価値がありそうなのは、 --diff オプションでしょう。CUI 大好き人間でも、ターミナル上で diff を読み解くのはさすがに辛いので、こういうときはグラフィカルなエディタの登場価値は大いにあります。

ここでは、上で説明した、オプション一覧の差分でも見てみますか。

code --diff .\stable.txt .\insiders.txt

バージョンが異なること、VSCode Insiders のコマンド名は、 code-insiders であること、あとは、先ほど言及した、 --extensionHomePath が変わったことなどが直ぐに分かると思います。

で、 VSCode の diff の素敵なのは、2個目のファイルの方(通常、新しい方)をその場で修正しながら差分を確認できる所なんですよね。これは便利(いや、他のエディタにもこの機能がある奴は知っていますけど・・・)。

f:id:espresso3389:20161208222204g:plain

code --list-extensions

--list-extensions はインストールされている拡張の一覧を「表示」します。

PS C:\Users\kawasaki\Desktop> code --list-extensions
abusaidm.html-snippets
austin.code-gnu-global
cssho.vscode-svgviewer
...

敢えて、「表示」を強調したのは、つい最近まで、本当に、「表示」しか出来なかったんです。 要は、リダイレクト出来ませんでした。 Issue としては、

Strange CLI behavior: CLI does not seem to write to either stdout (FD 1) or stderr (FD 2), making output impossible to redirect. #8585

で、この問題は実は、Electron の問題で、

Windows stdout writes directly to console and cannot be captured #4552

に影響を受けていました。で、この問題は既に直っており、どうやら、VSCode にも反映されている様です。「様です」というのは、実際、現状の安定版(1.7.2)ではちゃんとリダイレクトできるようになっているのですが、この Issue は close されてないという意味ですね。

で、リダイレクトしたかった理由は、それが出来ると、設定のバックアップをするスクリプトが書けるようになるからですね。 本来なら、 Dropbox で自動バックアップ!とか言いたいんですが、それをやると結構な頻度で、複数マシン間の競合とか発生して誰も幸せにならないので、最近は、自分の好きなタイミングでスクリプト実行の方が良いと思っています。

Code の設定をバックアップ

バックアップのバッチファイル(!)はこんな感じです。僕は基本的に、Windows の人なのでこれで十分なんですが、まぁ、 bashスクリプトを書くのも全然難しくないはずです。

@echo off

set CURDIR=%~dp0
set PROGDIR=%ProgramFiles(x86)%\Microsoft VS Code
set APPNAME=Code
set EXENAME=%PROGDIR%\bin\code
set VSCODEDIR=%APPDATA%\%APPNAME%\User
set CONFIGDIR=%CURDIR%\config

mkdir "%CONFIGDIR%" 2>NUL
copy /Y "%VSCODEDIR%\*.json" "%CONFIGDIR%"

call "%EXENAME%" --list-extensions > "%CONFIGDIR%\extensions.txt"

これを実行すると、 VSCode 安定版の設定と拡張の一覧「だけ」をバックアップします。 設定ファイル群は、

%APPDATA%\Code\User\*.json

をバックアップすればバックアップできますが、動的なデータは、sqlite の DB 的な奴で管理されています。 この辺もバックアップしても良いのでしょうが、バージョン間のデータ整合性とか、様々な事を勘案するとあまり積極的にバックアップすべき物ではない気がします。

ただし、DB 類をバックアップしないと、カラーテーマの設定などは保存できないようです。 この辺も .json に保存して欲しいんですけどね。

Code の設定をリストア

リストア側は、もうちょっと面倒です。 最後の for /f ... の部分で、 --install-extension というオプションを利用して、バックアップ時にインストールされていた拡張を一つずつインストールし直しています。もちろん、既にインストールされている拡張は普通にスキップされるので特に問題にはなりません。

@echo off

set CURDIR=%~dp0
set CONFIGDIR=%CURDIR%\config

set PROGDIR=%ProgramFiles(x86)%\Microsoft VS Code
set APPNAME=Code
set EXENAME=%PROGDIR%\bin\code
call :copy_files

goto :EOF

:copy_files
if not exist "%EXENAME%" goto :EOF

set VSCODEDIR=%APPDATA%\%APPNAME%\User
copy /Y "%CONFIGDIR%\*.json" "%VSCODEDIR%"

for /f %%e in ('type "%CONFIGDIR%\extensions.txt"') do (
    call "%EXENAME%" --install-extension %%e
)
goto :EOF

あとがき

まぁ、人と被らない内容を考えた結果、微妙にヌルい内容になってしまったので、これでどの程度、人の参考になるのかは未知数ですが、VSCode を活用するには是非とも知っておいた方が良い内容だと思います。多分。

で、 VSCode の安定版に関しては、実は、ちょうど、今日明日ぐらいで、 November/December Iteration Plan のコードフリーズって何それ?って感じですが、要はそろそろ、新しい VSCode の安定版がリリースされるって事です。

November/December Iteration Plan #15099

本当は、Iteration Plan っていうのは、月ごとになってて、いつも通りなら、VSCode の安定版は、各 Iteration Plan 完了後にリリースされる感じなんですが、あちらの国では、12 月後半はほとんど休みなので、12 月単独の Iteration Plan っていうのは、意味がないわけですね。なので、11 月の Iteration Plan は、ちょっとだけ長くなっています。

なので、来週末(向こうの日付で15日/16日) or 再来週の初めぐらいには、今年最後の VSCode 安定版がリリースされることになるでしょう。

この新しい安定版には、普通の人にも分かりやすいところで言うと、

  • カラー絵文字が使えるようになる
  • hotexit という、VSCode 終了時に編集中のファイルを明示的に保存しなくてもバックアップしてくれて、次回起動時に自動的に復帰してくれる機能
  • 設定ファイルの編集支援機能(かなり強力!)

などが導入される予定です。

絵文字がカラーになるので、拙作のsushi-vscodeで🍣を眺めて楽しんでくれると非常に嬉しいです。