眠るシーラカンスと水底のプログラマー

　ある程度納得が行ったので書き残しておく。

　EC-CUBE 4はWindows環境だと遅い。

　これはEC-CUBE 4というよりSymfonyの問題なのだが、Windows Subsystem for Linuxでも遅い。

　私はVisual Studio(Codeでもfor MacでもなくWindowsのVisual Studio)が好きなので、MacをメインPCにする気はない。

　ということで、Windows PC上でEC-CUBE 4を快適に触れる環境を考えてみた。

　IEDはVisual Studioは向いていないのでVisual Studio Codeを利用し、Xdebugでデバッグが行える環境を目指す。

動作は仮想マシン上

　LAMP環境はDockerに構築する。

　ハイパーバイザー型でも問題ないと思う。

SSHで接続して編集する

　DockerはSSHを立てないのが良いみたいだけど、Volumes設定でEC-CUBE 4のソースを共有するとWindows上にファイルを置いてしまい遅くなるので、ここは開発環境と割り切ってSSH接続を行う。

　Visual Studio CodeにはSSH FSというSSH接続ができる拡張機能があるが、PHP Debug拡張機能でXdebugを利用しようとするとpathMappingsがうまく動かないのでSSH FSは諦める。

　このページにssh:\\で書き出すと動くようなことが書いてあるが、試してみるとC:\\VSCodeDir\ssh:\\というパスになってしまう。現在は上手く動かないのかもしれない。書き方も[]で挟む時点でエラーになるし書式も変わっているのかも？

　SSH FSを利用できればより綺麗なのだが、諦めてwin-sshfsでマウントすることにする。

　あくまでSSHの接続先をWindowsのドライブのように見せるだけなので、Windows上にファイルは作成されない。ゆえに動作が早い。

　これならVisual Studio Codeで開くこともできるし、Xdebugでブレークポイントも張ることができる。

　pathMappingsもWindows上のファイルを指定する書き方でOK。

            "pathMappings": 
            {
                // win-sshfsで/var/www/htmlをGドライブにマウントした場合
                "/var/www/html/": "G:\\"
            },

　結構まどろっこしいのは認めます。

　みなさんはどうやって開発していますか？(そもそもWindowsで開発してない可能性・・・)

追記：2019年3月時点では、win-sshfs(正確にはWinSshFS Foreveryoneという名前らしい)の最新1.6.13でもファイル検索など無理をするとVS Code、win-sshfsもろともフリーズすることがあるので、デバッガーを利用しないなら、VS Codeの拡張機能でSSH FSの方がパフォーマンスは良い。

Tweet