LinuxとIntelliJを使ったWindowsでのプログラミング環境

このエントリーをはてなブックマークに追加

取り扱っているのはGolangですが、特にプログラミング言語は問わないと思います。

  • WindowsのGolang開発
    • IntelliJ便利
      • 機能がとても豊富
    • Windows上ではつらい
      • 開発ツールが少ない
      • LinuxはGUI使いづらい
    • LinuxのファイルをWindowsから変更する
      • 良いところ取り
        • 開発はWindows
        • 実行はLinux
      • ファイルはSambaで共有
        • ネットワークドライブをマウント
      • IDEデバッグは使えなくなる
        • そのときだけWindowsで動かすとか

Golang開発環境を整える

IntelliJでのGo開発環境

IntelliJ IDEAとGolang pluginはとてもよく動くため、
Golang開発に関してはこれを使うのが最も簡単に快適な開発環境を整えられます。
Go の開発環境は IntelliJ IDEA + golang plugin がマトモだった

VMwareに開発環境を整える

IntelliJもGolangはWindowsに対応しているため、比較的簡単に開発を行うことができます。
ですが、開発に便利なツールの多くはUnixの方が使いやすいことが多いため、
Windows上で開発するのは細かいところで面倒になることが多いです。
そのため、仮想マシンや別サーバにLinuxマシンを1台作り、
その中で開発をした方が何かと便利です。

ですが、LinuxのGUI環境は現状まともな環境がなく、とても使いづらいため、
開発以外の作業が発生する場合を考慮すると普段はできる限りWindowsを使用したくなります。
そこで、開発はWindows上のIntelliJ等で行い、実行環境や開発ツールはLinux上に整え、
それらをssh経由のCLIから操作するのが最も良い案になっています。

このような構成にすることで、Unixで動く便利なツールを利用しつつ、
Windowsの快適なGUI環境を利用することができます。
また、ファイルや実行環境と手元の環境とが切り離されるため、
複数の実行環境を切り替えたり、
マシンを入れ替える際に再設定する量を減らすことができるという利点もあります。

なお、私は手元のマシンのVMware上にLinuxを立てているため、転送速度はほぼ気になりません。

IntelliJで別サーバのファイルにアクセスする

残念ながらIntelliJはこのような用途を想定していないため、 別マシンの環境下で作業できません。

幸いなことに、Windowsがネットワークドライブとして別マシンのフォルダをマウントした場合、
IntelliJからは普通のドライブとして見えるため、別マシンのファイルにアクセスすることができます。

そこで、サーバ上の開発ディレクトリをSambaで共有し、
Windowsからネットワークドライブとしてそのフォルダをマウントしてあげることで、
IntelliJで開発を行うことができます。

私の環境では、以下のような設定をsmb.confに追加しています。

[global]
map archive = no

～中略～

[workspace]
   path = /home/username/workspace
   writable = yes
   guest ok = no
   guest only = no
   create mode = 0755
   directory mode = 0755
   share modes = yes

map archiveについてはこちらを参照
sambaでファイルを上書きすると実行属性が付いてしまう場合の対処

サーバと手元の環境を合わせる

補完機能を有効に活用するためにはサーバと手元に同じソースを持っておく必要があります。
ファイルを共有している場合、自分のプロジェクトに関しては問題ありませんが、
依存ライブラリ等に関しては意図的にそろえる必要があります。

幸いにも、私はgolangのパッケージ管理にgomを利用しています。
このツールはプロジェクト内に_vendorフォルダを作り、そこに依存パッケージを保存します。

そのため、IntelliJのProject StructureのGOPATHに_vendor/srcを追加することで、
依存パッケージの補完や、定義元ジャンプが効くようになります。

問題点

この手法ではIDEから実行することを想定していないため、
IDEデバッグなど、IDE経由で実行した際に動く機能が使えなくなってしまいます。
このような場合は常に同じ実行環境を維持しておき、
必要な時にIDEが実行することで回避できますが、あまり良い方法ではないです…

ですが、そもそもGolangのプラグインはそもそもまだデバッガに対応していないので、
大きな問題にはなっていません。