WSL 2 のデフォルトユーザー指定 (2つめのインスタンス用)

Visual Studio Code で WSL 2 と連携してろくに設定せずに Terminal を開くと root でシェルが起動してしまったりします。それでは困るので以下のコマンドでデフォルトユーザーを設定することになります。

ubuntu config --default-user blogger323

参考: https://docs.microsoft.com/en-us/windows/wsl/wsl-config#change-the-default-user-for-a-distribution

ところが、です。私の場合は以下の記事を参考にしてディストリビューションの位置を変えたり 2つめの WSL インスタンスを作ったりしています。

https://stackoverflow.com/questions/38779801/move-wsl-bash-on-windows-root-filesystem-to-another-hard-drive

私の場合、Ubuntu を export 後、Hetarena という名前で import して 2つめのインスタンスを作りました。さて、この 2つめのインスタンスのデフォルトユーザーを変えるにはどうしたらよいでしょう?

hetarena config --default-user blogger323

の様なことをやっても当然のごとく “Command Not Found” なわけです。

ググっても答えは見つからず、結局レジストリ内を検索して見つけ出しました。以下のキーに Linux uid を設定することでデフォルトユーザーを指定できます。

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{distro-id}\DefaultUid

ここで distro-id はディストリビューション (WSL インスタンス) に割り当てられた ID です。DefaultUid と同じ階層に DistributionName というキーがあるのでこれで見分けることができます。

ちなみにレジストリキーでググって後から以下の Issue を見つけることができました。私は試していないですが、Linux ファイルシステムの設定ファイルに書く方法もあるようです。(追記: Microsoft のドキュメントを改めて確認すると記載があったのでこちらの方が正規の方法ですね!)

https://github.com/microsoft/WSL/issues/3974

Anaconda と Visual Studio Code

Windows で Anaconda を使用して主に Python でコーディングしたりしています。Notebook 中心でスクリプトファイルをいじるときは Windows 用 Python 付属の IDLE を少し使うみたいな感じだったのですが、最近思い立って Visual Studio Code 環境に移行しつつあります。で、このエントリは Anaconda 用に Visual Studio Code を設定したときの覚え書きです。Python Extension をインストールした後あたりからの話です。

Python interpreter の選択

公式 Tutorial にも書いてあるしエディター上でもメッセージが出たりしますが、まずは Python interpreter を選択しなければなりません。ここで Anaconda 環境の python.exe を選択します。

conda.bat のあるところにパスを通しておく

作成したスクリプト実行時はまず conda コマンドが起動され、選択されている python.exe に応じた仮想環境が activate されてスクリプトが実行されるわけですが、この conda が見つからずエラーになってしまいます。Visual Studio Code のドキュメントをみると python.condapath を設定するとあるのですが、これが効きません。

ググってみると、この設定での成功例は見当たらないし、関連ありそうな Issue は Open のままっぽいので、素直にパスを設定することにしました。Windows 「システムの詳細設定」から環境変数で Path に “C:\ProgramData\Anaconda3\Scripts” を追加しています。

conda init powershell を実行する

Visual Studio Code 内で起動するターミナルではデフォルトで PowerShell が起動されるようです。Anaconda プロンプトを起動後、以下のコマンドを実行し Anaconda 関連初期化処理をPowerShell 用初期化スクリプト (profile.ps1) に追加します。

conda init powershell

PowerShell 実行ポリシー変更

デフォルト設定のままだと初期化用の profile.ps1 が実行許可されずエラーとなってしまうため、PowerShell Execution Policy を緩くします。ここではローカルのスクリプトは署名がなくても実行できるようにします。(RemoteSigned: 詳細はこちら)

以下を管理者権限で起動した PowerShell 上で実行します。

 Set-ExecutionPolicy RemoteSigned 

以上で Python スクリプトを Visual Studio Code から起動できるようになったはずです。

ということをもろもろ確認しながら書いていたらここの回答そのままじゃん、と見つけて思ってしまいました。やはり探すべきは stack overflow ですよね。

Minified JavaScript と Source Maps、とか

あっと言う間に 2015年が始まって 1ヶ月半が経過してしまいました。 本業がバタバタしているのもあってこれが今年初のエントリだったりします。

今回は PhpStorm を使った開発関連の小ネタを 2つほど。 PhpStorm といいつつ PHP には関係ない部分なので WebStorm でもオッケーなはずです。

Minified JavaScript とデバッグ

WordPress プラグインの開発に PhpStorm を使っているわけですが、いわゆる .min.js ファイルを作って圧縮しつつ、ソースファイルを使ってデバッグするための方法を探していました。 Source Maps ファイルを使えば良いということはわかっていたのですが、今一つうまく動かないのでちょっと気合を入れて調べてみました。

すると日本語で答えが見つかったので感動しました!

重要なのは Closure Compiler に以下のオプションを与える部分です。

--create_source_map $FileNameWithoutExtension$.min.js.map 
--output_wrapper "%output%//@ sourceMappingURL=$FileNameWithoutExtension$.min.js.map"

こちらの記事でも説明されていますが、圧縮して作った .min.js の最後に Source Maps ファイルの URL を埋め込まなければなりません。 以下のような内容を最後に入れるのです。

//@ sourceMappingURL=standard-widget-extensions.min.js.map

これを行うために –output_wrapper オプションを使って出力の最後にソースマップ用 URL を追加しています。

これで圧縮前の JavaScript ソースを使ってデバッグできるようになりました。 英語も含めて探したのですが、見つかったのは先の日本語記事のみ。 バシャログさん、有益な情報ありがとうございます。

ちなみに YUI Compressor では Source Maps 出力用オプションを見つけることができず、UglifyJS は調べてません。

Git merge と PhpStorm

WordPress プラグインは一人で開発しているので、なるべくマージが発生しないようにしてきましたし、やむを得ない場合はできるだけコンフリクトが生じないようにしてきました。 ところが最近、開発を進めてだいぶコードをいじった後に、リリースしているバージョンの微修正版を出さなければならない状況が生じました。 もう仕方ないのでブランチを切ってみました。 そして、恐る恐る PhpStorm 上で git merge をしてみました。

そしたら、思ったより簡単。 PhpStorm (WebStorm) はマージツールとしてとても扱いやすいです。 下の画面の様にマージ結果を中心に 3つ並べて「×」や「>>」、「< <」を使って操作することができます。 merge (phpstorm)

以下の記事に従えばコマンドライン git のマージツールとして PhpStorm (WebStrom) を登録することもできます。

結び

今年も相変わらずマイペースにブログを続けていこうと思いますので、よろしくお願いします。

Angular.js のチュートリアルを Windows で実行するために

Angular.js 公式チュートリアルの「Working with the code」(環境構築から最初のテスト実行まで) を Windows 環境で実行するための補足です。 あくまでも補足ですので、手順自体は公式サイトを参照してください。 Windows Server 2012 と Windows 7 で試しました。

関連ツールのインストール

まず、必要なものから。

  • Node.js をインストールする。インストーラ (.msi) をダウンロードして実行でオッケー。
  • Git for Windows をインストールしておく。インストールの際に ‘Use Git from the Windows Command Prompt’ を指定するか、コントロールパネルから Git の bin ディレクトリ (デフォルトでは \Program Files (x86)\Git\bin) にパスを通しておく。
  • Chrome をインストールしておく。
  • Java 実行環境をインストールしておく。

その後は「Node.js command prompt」を起動して説明通りにコマンドを入力しますが、git や java へのパスが通っていないと失敗するので気をつけましょう。

Optional となっていますが、以下も実行しておきましょう。

npm install -g bower

テストの実行

テストの仕方ですが、チュートリアルで説明されている通り、

npm start

を実行すると 8000/TCP でテスト用サーバーが動きます。 そこで別の「Node.js command prompt」を起動し、テスト用のコマンドを実行します。

Karma による Unit Test では Chrome が起動して「connected」と表示され、「何じゃそりゃ?」という感じなのですが、コマンドプロンプトにテスト結果が SUCCESS と表示されていればオッケーです。 テスト後は Chrome を終了しても再起動してしまうので、コマンドプロンプトの方に Ctrl+C を送ります。

きちんと説明を読むと変更を検知してテストし直すので Karma は起動しっぱなしにするのがお勧めと書いてあったりします。

Protractor による End to End Test はテストしている感があって面白いですね。

英語の苦手な人も頑張ってみましょう。

SWE の JavaScript プログラミング

Standard Widget Extentions (SWE) という WordPress プラグインを作って公開しています。 先日は SWE のスクロール時固定機能 (Sticky Sidebar について「そこらへんに落ちているサンプルコードとは動きが違うんだよ」という話を書きました。 今回は JavaSciprt 的にいろいろ苦労したところを書いておきます。

なお、ここで紹介している関数は特に断りがなければ jQuery の API です。

幅やマージンの %指定

レスポンシブ Web デザインでは以下のように width や margin がパーセント表示で比率指定されていたりします。 テーマ製作者はピクセルの比率から値を計算しているのでこのように結構エグい小数になっていたりします。

.content-sidebar {
  margin-left: -29.04761904%;
  width: 29.04761904%;
}

ここで一つ問題となったのが、width が %指定のままで position = fixed にして位置を固定すると比率の基準となる要素が変わるため幅が変化してしまうことです。 これを避けるには一度取得した値を再度設定しピクセル値で固定することです。

var w = $('#sidebvar').width();
$('#sidebar').width(w);

では、ブラウザがリサイズされたときはどのようにすれば良いでしょう? リサイズ前の幅のままではレイアウトが意図通りになりません。しかし、新しい幅はどうやって計算すればよいのでしょうか? 比率を取得するために CSS ファイルを自力で読まねばならないのでしょうか…。

わかってしまえば簡単なのですが、一旦 width をクリアすることで解決します。

$('#sidebar').css('width', '');

jQuery API リファレンスをよく読むと書いてあるのですが、空文字列に指定するとこれまでの API 経由で設定したスタイル指定をクリアし CSS ファイルの記述通りに振る舞うようになります。まとめて書くと以下の様に一旦クリアし再度取得したピクセル値で設定することになります。

$('#sidebar').css('width', '');
w = $('#sidebvar').width();
$('#sidebar').width(w);

一瞬なんだかわからないコードですよね。

サイズ関連

.width() で取得した値と .css(‘width’) で取得した値は異なることがあります。 一方が 250 なのに他方は ‘310px’ などと返ってきたりします。 型の差は置くとして、異なる数値になっているので困ります。 これは box-sizing プロパティのせいだったりするのですが、この値を見て動作を変えるようなコードを書くのはいろいろ面倒です。

それで結局どうしたかというと以下のようにしました。

  • 位置計算等に使用する幅の取得は .outerWidth(true) を使って、いつでも border や margin 込みの値を用いる。 jQuery の .width(), .innerWidth(), .outerWidth() は box-sizing の値に依って動作が変わることはない。
  • 先述の width の操作についてのみ、取得・設定とも統一して .css() で行う。

このように jQuery の関連関数は box-sizing プロパティに依らず使えるので便利です。

座標関連

座標取得には document を基準として位置を取得できる .offset() が便利でした。 ただし、以下のように .css(‘top’) を使って操作するときとで対象としている座標の位置が異なるので注意が必要です。

jquery-offset

ちなみに position = absolute のときの基準要素を見つけるには .offsetParent() が便利です。jQuery にはいろいろな関数が揃っていますね。

position と z-index

position = static だと z-index が指定されているテーマで不具合を起こすため、position = static を使うのでなく position = relative で (top, left) = (0, 0) としています。

小数点の扱い

サイズ関連でもう一つ困ったのは小数の扱いがブラウザによって異なることです。 整数 (ピクセル値) に直す時に四捨五入なのか切り捨てかみたいな話です。 深入りしたくなかったこともあり細かい挙動は忘れてしまったのですが、気になる方は検索してみるとこの話題を扱っているサイトが見つかると思います。 SWE では先の .css(‘width’, ”) を使うテクニックにより、これらの問題を避けています。

というわけで、Standard Widget Extensions のサイドバースクロール時固定機能はその辺のサンプルコードと違うのです! 興味がわいた方は使ってみてください。

Minecraft Forge で Mod づくり

子供が Minecraft にハマっていて Mod づくりに興味がありそうなので、とりあえず開発環境を用意してみました。 ネット上を探すと Mod 製作の情報はあるにはあるのですがどうも古いようなので、自分の行った手順を簡単にまとめておきます。

自分の使った Minecraft/Minecraft Forge バージョンは Windows 用の 1.7.10 です。

環境の構築

以下のように環境を構築しました。

  1. まずは Minecraft 1.7.10 をダウンロードし、一度は実行しておく。
  2. JDKEclipse をインストールしてする。 私の場合は、JDK 1.8.0 の 64ビット版と Eclipse Standard 4.4 (Luna) の 64ビット版を入れました。
  3. ダウンロードページより、1.7.10-Recommended の Installer-Win と Src をダウンロードする。 Installer-Win の代わりに Installer (.jar ファイル) を使うのも可。
  4. Installer-Win を実行する。 Minecraft 1.7.10 を起動したことがないと失敗するので、1度は起動しておく。
  5. ダウンロードした Src を適当なディレクトリに展開する。
  6. Src 展開後のディレクトリ内に存在する README.txt の手順に従う。具体的には以下を実行。

    • gradlew setupDevWorkspace
    • gradlew eclipse
  7. Eclipse を起動し、Src 展開後ディレクトリ内の eclipse ディレクトリをワークスペースとして指定する。

ここまでで作業環境ができます。

プログラムの作成

ワークスペースを開くと Minecraft プロジェクトが存在します。 その中の src/main/java にサンプル ExampleMod.java があります。 自分用の package をこの隣に作成後、ExampleMod.java をそこにコピーし作業を始めればよいと思います。

また、実行時 Program arguments として以下を指定する必要がありました。

--assetIndex 1.7.10

これがないと実行時に以下のエラーが発生してしまいます。

Exception in thread "main" java.lang.RuntimeException: java.io.FileNotFoundException: C:\Users\blogger323\.gradle\caches\minecraft\assets\indexes\{ASSET_INDEX}.json (指定されたファイルが見つかりません。)
	at com.google.common.base.Throwables.propagate(Throwables.java:160)

開発を進めるには

結構困るのが公式の API のリファレンスマニュアルが存在しないことです。 ここまで検索して探してみた結果は、どうやらデコンパイルされた「ソースを読め」ということのようです。 古いサンプルコードは動かすのに修正が必要で、1.7.10 の情報はまだ少ないようです。 リファレンスとしてはダウンロードページより JavaDoc をダウンロードできます。

ついでに忘れないように用語メモ。 今ひとつそれぞれの境界がわかっていないですが。

Forge
Mod 開発フレームワーク
FML
Forge Mod Loader
MCP
Mod Coder Pack。開発用基本ツールパック

Mod の置かれる場所

インストール後は、Minecraft 起動時に「Forge」プロファイルを選択すると Forge の Mod を読み込むようになります。 Mod をただ使うだけであれば %APPDATA%\.minecraft\mods の下に置けばよいです。 参考まで。