Proxy 下で vscode の WSL 拡張へ接続できない

Windows 上の Visual Studio Code (以下、 vscode) で、WSL 上のファイルやシェルを使えるようになる、 Remote - WSL 拡張機能。

これを、プロキシ環境下でインストールしたり更新したりすると、 vscode から WSL 環境ににアクセスするときに、

VS Code Server for WSL closed unexpectedly.
Check WSL terminal for mor details.

とエラーになってしまう。

WSL ターミナルのログを見てみると、だいたい以下のようになっていて、どうやら update.code.visualstudio.com から VS Code Server の更新版のファイルをダウンロードするのに失敗しているように見える。

Starting VS Code Server inside WSL (default distro)
Extension version: 0.39.5, Windows build: 17763. Multi distro support: disabled. WSL path support: enabled
Probing if server is already installed: C:\WINDOWS\System32\wsl.exe  -e sh -c "[ -d ~/.vscode-server/bin/3db7e09f3b61f915d03bbfa58e258d6eee843f35 ] && echo found || echo missing"
No server install found on WSL, downloading server on client side: C:\Users\user\AppData\Local\Temp\vscode-remote-wsl\3db7e09f3b61f915d03bbfa58e258d6eee843f35\vscode-server-linux-x64.tar.gz
Unable to detect if server is already installed: Error: connect ECONNREFUSED 104.42.78.153:443
Launching C:\WINDOWS\System32\wsl.exe sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 3db7e09f3b61f915d03bbfa58e258d6eee843f35 stable .vscode-server 0  --disable-telemetry' in c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-wsl-0.39.5
WSL version: 4.4.0-17763-Microsoft 
Updating server...
Updating VS Code Server to version 3db7e09f3b61f915d03bbfa58e258d6eee843f35
Removing previous installation...
Downloading:     
Failed
--2019-09-11 20:50:12--  https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable
Resolving update.code.visualstudio.com (update.code.visualstudio.com)... 104.42.78.153
Connecting to update.code.visualstudio.com (update.code.visualstudio.com)|104.42.78.153|:443... 
failed: Connection refused.
ERROR: Failed to download https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable to ~/.vscode-server/bin/3db7e09f3b61f915d03bbfa58e258d6eee843f35-xxxxxxxxxx.tar.gz
VS Code Server for WSL closed unexpectedly.
For help with startup problems, go to
https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips

どう解決したものか。


そもそも wget でダウンロードができる状態なのか

続きを読む

同一ファイルに対して、 複数種類のファイルハッシュを高速に計算する

ネットワークドライブ上の GB オーダーのファイルに対して、複数のハッシュアルゴリズムでファイルハッシュを計算する必要に駆られていた。
「そんなシチュエーションが本当にあるのか?」と思うかも知れないが、あったのだから仕方ない。

最初は、 PowerShell を使って 愚直に Get-FileHash を 2回 計算していた。
しかし当たり前だが、 2回ファイルをダウンロードすることになるこの方法は遅くて仕方ない。

ということで、 C# でコンパイルしたコード上で、 一度メモリに読み込ませてから複数のハッシュアルゴリズムで計算できるようなコードを作成した。

バッファーサイズを 80KiB 程度とすると、 .NET の仕様で 85KB を境にメモリの扱いが変わる (LOH と呼ばれる特別なヒープに移動する) ことから、 このサイズを超えると一般的に動作速度が下がると言われている。
しかし、今回のコードの場合バッファーが小さいと、 Task 周りの処理がボトルネックになってしまうので、 8MiB くらいのサイズとしている。

80KiB としているのは、 .NET mscorlib の System.IO.Stream.CopyTo メソッドなどでもおなじみなのだが、これが必ずしも正解とは限らないわけだな。


パフォーマンス

800Mbps 位でシーケンシャルリードできるリモート上の 4GB のファイルを、 4回 ずつ計測した平均を計測した。
Get-FileHash の 2種類目 以外はクライアントキャッシュが効かないように注意し、 計測の各回でハッシュを計算するファイルはそれぞれ別のファイルで、中身はランダムバイナリとした。
Get-FileHash については、 計測の各回では同じファイルに対して -Algorithm パラメータを変えて複数回連続で呼び出した。

計算したハッシュの種類 Get-FileHash 上記の改良スクリプト
1種類 (SHA1) 48.8s 43.3s
2種類 (MD5, SHA1) 60.4s 44.2s
3種類 (MD5, SHA1, SHA256) 83.3s 48.2s

ん? 計算したハッシュが 1種類 の場合でも、改良スクリプトの方が早いぞ?


うわっ… HashAlgorithm.ComputeHash の実行速度、低すぎ…?

PowerShell v5 相当

PowerShell v6 相当

上記のように、 Get-FileHash は、内部的に HashAlgorithm.ComputeHash でハッシュ計算を実行している。

で、その HashAlgorithm.ComputeHash がどうなっているかというと、 4KiB 毎に ファイルの読み込みと、 ハッシュストリームへの書き込みを 同期的に 行っている。

ファイルの読み込みも、 (使うアルゴリズムにもよるけど) ハッシュの計算も、 どちらもコストがかかるので、同期的にやってたらそりゃ遅いわ。

LINEマイカード をワンタップで起動するショートカットを作る裏技 【非公式】

LINE のサービスのひとつに、「LINEマイカード」というものがある。
いくつかの種類のポイントカードをスマホにまとめる機能だ。

ポイントカードで財布がパンパンになりがちな私には、なかなかもってこいなサービスだ。
# 正直、2018年10月にロンチしてからこの数ヶ月間、カードの種類が大して増えないので、今後も使える将来性のあるサービスなのか正直怪しいのだが…

しかし、この LINEマイカード、実際使い始めてみると、ある致命的な問題に遭遇する。
LINEマイカード の起動するまでが遠い のだ。

例えば、適当な画面から LINEマイカード を開こうとすると、

  1. ホーム画面に移動する
  2. LINE を起動する(おそらくトーク画面だろう)
  3. トップページに移動する
  4. ウォレットタブに移動する
  5. マイカードアイコンを選ぶ
  6. 使いたいポイントカードを

という、 6動作も必要となる。 ((1)はいらんやろという異論はあるだろうが)

レジでの会計時にパッと使いたいのに、こんなにももたつく操作では大変使いづらい。

LINE Pay や LINE Out などであれば、 LINE アプリ内からホーム画面にショートカットを作ることができる。
しかし、 LINEマイカードについてはそのような機能はない。 (2019年3月現在)

ということで、別の方法で Android のホーム画面からワンタップで LINEマイカードに起動する方法を考えてみよう。

詳細な手順は異なるが、 考え方自体は同じなので iPhone でも実現できるはずだ。

続きを読む

Twenty Eleven Theme Extensions が SSL化 でエラー

当ブログでは、 WordPress の Twenty Eleven テーマを使っている。

このテーマでば、なぜかシングルページの表示や個別記事のページでサイドバーが表示されない。

当ブログのアクセスのほとんどは、 検索からの個別記事のページへの流入なので、個別記事へのサイドバーの表示は行っておきたいところだ。

それを実現するのが、 Twenty Eleven Theme Extensions プラグインだ。

とても古いプラグインだが、 Twenty Eleven テーマの最新版でも問題なく動いている。

ところが、 このプラグインを有効にしたところ、 Google の Search Console で怒られるようになってしまった。

調べてみたところ、 /plugins/twenty-eleven-theme-extensions/moztheme2011.css の配信が This request has been blocked; the content must be served over HTTPS. でエラーになってしまっているようだ。
このブログは SSL化 され https:// で配信されているのに、プラグインの CSS が http:// で配信されているためだ。

これを修正してみよう。

続きを読む

Pydroid で オフライン&セルフホスト の Web アプリを動かす

運用時にネットワークにつながっていない Android タブレットで、 自作のアプリケーションを 簡単に 動かすには、どうしたらよいだろうか?

.apk ビルドしてインストールさせる?いやいや、手軽からはほど遠いだろう。

現在のトレンドは PWA で Service Worker を組み合わせてキャッシュさせる方法だろうか。
PWA 配信するには https のホスティングを用意しなくてはならないし、ブラウザのキャッシュ整理したらデータが吹き飛んでしまう。

ここで私は、 Android 上で Python を動かしてセルフホストさせる方法 を提唱したい。

続きを読む

Flask + jinja でレイアウトの指定 (extends タグ) のテンプレートを ソースコード文字列 で指定する

Python の軽量な Webアプリケーション フレームワーク として有名な Flask。
この Flask を使うと たった一ひとつのソースファイルで簡単に Webアプリケーション を作成できる。

Flask では Jinja2 というテンプレートエンジンを採用している。
通常はテンプレートソースを .html ファイルにテンプレートソースを書き出して ファイル名を指定してそのテンプレートを読み出すのだが、 flask.render_template_string を使えば Python ソースコード上で定義した テンプレート文字列 を使うことができる。

しかし、 extends ステートメントや include ステートメントを使ってレイアウト用などのテンプレートを呼び出す際に、 そのテンプレートを ファイル名 で指定する方法の情報しか出てこない。
これでは、 ひとつのソースファイルで記述できない。
テンプレートソース文字列 を使ってテンプレートの継承を行う方法を、メモがてらまとめておく。

以下のサンプルは Flask を使ったものだが、 Django で Jinja2 を使用した場合も同じように対応できると思われる。


サンプル実装

extends タグinclude ステートメント では、 与えられた文字列のテンプレートファイルをテンプレートローダーが探し出して、 テンプレートの継承関係を解決する仕組みになっている。
Jinja のドキュメントには書かれていないが、 文字列ではなく Jinja の Template オブジェクト を与えると、そのテンプレートをそのまま使ってくれるようだ。

つまり、 あらかじめ Template オブジェクトを作成しておいて、 それを jinja_env.globalsrender_template_string のキーワード引数によってテンプレート内の引数に渡し、 最終的に extends タグに渡るようにすればよいのだ。

サンプルコードは以下の通り。

続きを読む

Selenium でページ全体のスクリーンショットを撮る (Python)

02/25 更新: Chrome で水平スクロールバーがスクリーンショットに写ってしまう問題を修正。

Selenium を使って自動テストを行っていると、表示された結果のスクリーンショットを撮って保存したい時がままある。

ところが、 Chrome や Firefox で Selenium のスクリーンショット機能を使うと、 ウィンドウに表示されている内容だけしか取得できない。
(ブラウザやそのバージョンによって動作が異なる)


この記事によると、これは Selenium の仕様らしい。

ブラウザごとの挙動の差はさておき、 ウィンドウサイズでの取得となってしまう Chrome と Firefox で、何とかページ全体のスクリーンショットを保存したい。
ここでは、 Selenium の Python Binding を使って、実現する方法を考えてみる。

続きを読む

ideapad Miix720 Core i7 16GB ~2018年のベストバイ~

01/15 追記: 価格.com のページは残っているが Lenovo の直販ページへのリンクが切れていて、どうも Lenovo 直販モデルの扱いがなくなってしまっているようだ…
販売代理店モデルはまだあるようなのだが、そちらはメインメモリサイズが 8GB にとどまってしまっている。
CES 2019 で後継モデルが発表されたのかと思いきや、そんなことは全くなく、リーズナブルな Surface ライクのサイズ&性能のモデルがなくなってしまったのが残念でならない…

唐突だが、 2018 年のベストバイだった Lenovo の 2-in-1 タブレット, Miix 720 の Core i7 16GB モデル をレビューしたいと思う。
(2018年中の記事0は悲しいからね)

のっけから話の腰骨を折るが、 このモデルの発売日は 2017年 の夏ごろで、 2018年 に発売されたものではない。
にもかかわらず挙げているのは、 2019年も迫る現在でもこの端末に相当する良機が見つからないからだ。


購入経緯

まず、私はこれまで Surface Pro 2 (Core i5, 256GB SSD, 8GB Memory) を使っていた。
2013年当時は、 ペン同梱の本体と Type Cover をセットにしても14万円くらい購入ができた。
かれこれもうまる5年使っているので、 バッテリーがヘタヘタだし、 少しの衝撃で勝手に再起動されるようになってしまったので、 これの代替になるマシンが欲しかったのだ。

そこで、 2018年 にこれから数年使うために求めたのが以下の通り。

  • 筆圧対応ペン付きタッチパネル搭載 ラップトップ または 2-in-1
  • メモリは 人権 最低 8GB, できれば 16GB
  • ストレージは 256GB 以上
  • モニターは WUXGA 以上
  • SD または micro SD カードスロット

これを、 Surface Pro 5 や 6 で揃えようとすると、
8GB メモリですら 16万円、 16GB メモリにこだわると 27万円 などというとても手が出さない値段になってしまう。

ところが、この Miix720 であれば実質 12万円 ですべてがそろってしまうのだ。


Surface Pro 2 と比べると、ふた回りでかいが、携帯性は高いので全然問題ない。


主な仕様と特徴

主な仕様は以下の通り。

続きを読む

pipenv の仮想環境のフォルダ名のルール

Python におけるパッケージ管理と言えば、 以前は virtualenv/venv で仮想環境を作成し、 pip を使って その仮想環境にパッケージをインストールするのが、おなじみの方法だった。

node.js の npm や .NET の dotnet restore などに慣れている人々にとっては、 環境の管理やパッケージの管理が別々だったり、 ひとつのファイル+ひとつのコマンド で環境を復元できないのは、 ソースコード管理がスマートにできず、非常に面倒に感じる。

このため、 Python にも 仮想環境・パッケージ管理を統合するツールがいくつも生まれては消えていった。
そして、最近になってついに、 Python.org 公式が推奨する Python パッケージ管理ツールとして、 pipenv というものが登場したようだ。 (→ Python.org)

pipenv の仮想環境の場所

pipenv install コマンドを使ってパッケージをインストールすると、 npm の package.json にあたる Pipfile というファイルがカレントディレクトリにできあがるが、 npm の node_modules にあたるようなパッケージがインストールされた仮想環境のフォルダは、カレントディレクトリは(標準の設定だと)作成されない。
(なお、 環境変数 PIPENV_VENV_IN_PROJECT に何らかの値を設定した場合は、 カレントディレクトリの ./.venv/ ディレクトリが仮想環境のフォルダになる。)

その仮想環境のフォルダの場所は pipenv --venv コマンドで調べることができる。
Windows の場合は、 %USERPROFILE%/.virtualenvs/ に、環境毎のサブディレクトリが作成されているはずだ。

その仮想環境ディレクトリの名前の前半は、 Pipfile が存在するフォルダの名前になるが、 最後の9文字はなにやらランダムのような名前がつけられている。
例えば、 D:/pipenv/ で pipenv を初期化した場合、 %USERPROFILE%/.virtualenvs/pipenv-LAdtM08T/ が作成されるだろう。

はたして、この文字は何なのか?

続きを読む

Pandoc の Portable Windows バージョンを作る

Pandoc は、 HTML や、 Markdown, Textile, LaTeX などはじめとした、豊富な各種マークアップ形式を、別の形式に変換できるコマンドラインツールだ。

例えば、 textile → markdown 変換 とか、 HTML → markdown 逆変換 といったようなことができる。

何ができるかは、 Pandoc ユーザーズガイド あたりを参照してほしい。

さて、 この Pandoc の Windows 版は msi のインストーラ形式でしか配布されていない。

このインストーラでインストールすると、 ユーザディレクトリの %LOCALAPPDATA%\Pandoc\ (もしくは %ProgramFiles(x86)%\Pandoc\) に実行ファイルを展開して、 PATH を通してくる。
どうやら、システムディレクトリにファイルを置いたりしないようなので、 正直これだけのためにインストーラを実行して、 PATH や レジストリを汚すようなことをしたくない。

ということで、 msi インストーラから、 インストールをせずに実行ファイルだけ取り出して、 Portable 版を作成してみよう。

続きを読む