Windows 10 でサポートされるようになった WSL(Windows Subsystem for Linux) 、しばらくメイン機が Windows 7 のままだったので、あまり使うこともなかったのですが、業務用のマシンも5月に Win10 に置き換えられることになったことと、プライベートで購入した GPD Pocket 2 を開発機として活用する目的もあって、これまで以上に気合を入れて使ってみることにしました:
windows-vs-ubuntu



【これまでの開発スタイル】
WSL の話の前に、これまでの自分の開発スタイルを簡単に紹介しておきます。基本 Linux 上でソースコードを書いて、同 Linux 上で動かしてテストしていました。最大の理由は「本番で動かす際のサーバーはほぼ Linux 」かつ「自分は vi エディタ派」だからでした。一方、業務で支給されているマシンはメイン機が Windows (7) ノートPCで、サブ機が macOS デスクトップ(iMac)、個人で所有する中に Ubuntu デスクトップ機が1台存在する、という状態でした。つまりコーディングする時は
  • Windows に Linux の仮想マシンを入れて、そちらにログインしてコーディング
  • Windows から別環境の Linux(クラウドとかラズパイとか)にリモートログインしてコーディング
  • macOS 上のターミナルからエディタを起動してコーディング
  • Ubuntu デスクトップをインストールしたノート PC からコーディング
するような感じでした。

なお Windows 上でコーディングして Windows 上で動作テスト、というスタイルは本番サーバーが Windows とわかっていればやるかもしれませんが、色々挙動の違いが気になってしまい、あまりやっていません。

上記4つのうち、上2つは面倒なんですが、本番環境に近い Linux 上での動作確認までできるという点が魅力です。また開発以外の資料作成時にデスクトップアプリ(パワポ、エクセル、ノーツ、画像リタッチ、あと ATOM みたいな IDE 環境、etc・・・)を利用する際においては使いやすい Windows 版が使える点が魅力でした(ぶっちゃけ、macOS 版のエクセルや日本語変換の完成度って・・・(^^; )。一方で実質的には開発用に(仮想的な)別環境を1つ作る必要があるため、ディスク利用効率もよくないし、その点においては資料作成含めてすべて1台の macOS 内で完結できる3つ目の開発スタイルも、これはこれで優れていると感じていました。 4つ目の Ubuntu デスクトップ機を使うのも3つ目と同じで悪くはないのですが、やはり開発作業以外のデスクトップ作業では Windows に一日の長があるように感じます(Micorsoft Office も Linux 版は提供されてないし)。Ubuntu でプレゼン資料作るのはまだちと厳しいと感じる現実があります。


【WSL を併用した開発スタイル】
今回 WSL を使って開発環境を構築するにあたり、このような責任分担を行いました:
サーバー部分: WSL
開発・デスクトップ作業: Windows


つまり、ソースコードを置いたり、アプリケーションサーバーを起動したり、そのアプリケーションサーバーから開発したアプリケーションを起動したりする部分は WSL を使います。 一方、ソースコードを編集したり、ソースコード以外の資料ファイル作成など(ウェブでググるのも含める)といった GUI のデスクトップ作業は Windows を使うことにします。それぞれの得意分野を活かせるような分担にしたつもりです:
2019040800



この環境で開発作業を行うために2点ほど環境設定を行いました:

(1) ソースコード共有
サーバーが WSL で、クライアントおよびデスクトップ作業は Windows 。と、キレイに分けているように見えるかもしれませんが、ソースコードだけは共有する必要があります。つまり Windows(クライアント)側でソースコードを編集し、その編集されたソースコードが WSL 上で実行される必要があるのでした。

このため以下の手順を実行して、Windows / WSL 両方の環境から1つのソースコードが参照できるようにしました。まず Windows のコマンドプロンプトを起動し、ホームディレクトリに src/ という名前のフォルダを作成しました。ソースコードはこのフォルダ内に作ります:
> cd \Users\(Windows のユーザー名)

> mkdir src


次に WSL のシェルを起動して、上記で作成した src フォルダをホームディレクトリにシンボリックリンクします。WSL からは Windows の C ドライブが /mnt/c/ フォルダにマウントされています。この情報から上記で作成したフォルダは /mnt/c/Users/(Windows のユーザー名)/src に作られていることになるので、WSL のシェル上で以下のように実行します:
$ cd

$ ln -s /mnt/c/Users/(Windows のユーザー名)/src

これで Windows のホームディレクトリ以下に作成した src フォルダが、WSL では ~/src フォルダとして存在するようになりました。これで Windows で編集したファイルを WSL からも参照できるようになったので、そのまま WSL のアプリケーションサーバー上で動かすことができるようになりました。


(2) ATOM エディタの vim 化
次に Windows 向けのテキストエディタのカスタマイズです。個人的に vi/vim 派なので、テキストエディタでもこのキーバインドを使いたいのでした。

例えば Windows 向けの vim を導入する、というのも1つの案だと思いますが、自分は ATOM エディタに vim 用プラグインを導入して vim っぽく(?)使えるようにカスタマイズしました。

具体的には(ググればわかると思いますが)ATOM エディタに vim-mode-plus プラグインを導入して、ATOM を vi/vim キーバインドで使えるようにしています。


これら2つのカスタマイズによって、
①アプリ開発時に、まず Windows で WSL と ATOM を起動し、
②ATOM でソースコードを編集し、
③WSL 側で編集したソースコードをアプリケーションサーバーで起動してテスト、
④Git へのコミットや本番サーバーへのデプロイは WSL から行い、
⑤ドキュメントや資料は Windows の Office やデスクトップツールで作成
という、かなり使い勝手のよい作業分担環境を作ることができました。

一方でこの環境を使う場合の注意点もあります。最大の問題は「文字コードの違い」を意識する必要があることです。Windows 側で編集するソースコードの文字コードは原則 UTF-8 にする点に注意しましょう。

WSL はまだ動かないツールがあったり、デーモンは手動起動が必要になるなどの制限事項もありますが、ウェブアプリケーションの開発環境として使う限りにおいてはあまり苦にならないと思いました。