Fresh PHP development noIDE adventures
Tags: php, linux, windows
Published: 2019-05-24 16:19:55

---
title: Fresh PHP development noIDE adventures
published: true
description: I signed a contract and was suddenly swooped off to a foreign fairyland so I helped myself to some convenience
tags: PHP, linux, windows, 
---
Instant interaction response and common interfaces across different development tasks help my productivity immensely. Having started a new job in PHP web development where the host OS on the everyday workhorse is Windows 10 this turned out to be a bit of a challenge. I'll be doing legacy code maintenance in parallel with fresh development of the next, well thought out version of the same application, mainly on a PHP/MySQL/Linux stack. 

As it happens, targeting a Linux server environment from a Windows development box isn't exactly straightforward. If I'm not mistaken it is common in this situation to pay for and run a big IDE and possibly order around a fleet of handcrafted containers and wrestling with undebuggable Services rather than good old daemons. 

I immediately tried out the Windows Subsystem Linux, but it turned out to be somewhat underwhelming. Somehow I had expected more than the lack of GUI and workarounds with MobaXterm being terribly wobbly at best (just don't go there) so I guess I'd been away from Microsoft fairyland long enough to forget the gritty struggles one must endure here. 

However, I'm accustomed to SSH:ing into remote servers and fine with doing work in the terminal, which is basically the experience one gets with the WSL. Quite far from the full unixlike splendour but it is good enough. 

There I mainly do work on the new application, with [tmux](https://github.com/tmux/tmux/wiki), [vim+plugins](https://vimawesome.com/) and [ripgrep](https://github.com/BurntSushi/ripgrep) as the primary tooling, all of which install and run nicely under WSL. Once upon a time I used tag files but ripgrep chipped away at that and this time I haven't bothered with them at all. It's just too nice to 

```
:!rg 'function weirdMethod' -A 5 -B 5 
```

from within vim (or command line equivalent in a fresh tmux pane) and instantly get a view of how weirdMethod() is defined and commented and where it is. Especially when working with huge files that mix two browser layout languages, one browser scripting language and two backend languages freely and sometimes erratically it helps a lot to have a consistent, fast and regex capable interface to them. 

Filesharing with the WSL is fairly convenient, instead of using SSH/SFTP for transfer one can reach the host filesystem through a mount point. Other than that it is the regular headless VPS experience for the most part.  

Since I needed a setup with particular versioning of PHP, web server and so on, I looked into Hyper-V and running a Linux VM as well. I'm just not a container type of monkey. This turned out to be easy at first, a quick reboot to turn on the hardware hypervisor support in BIOS and it was good to go with a well supported Linux image. 

VM:s are usually a bit sluggish but I soon found out that Hyper-V is aimed solely at mid to high end servers running headless guests. The UI was lagging intensely and constantly littered with graphical noise, for example, switching between workspaces in the window manager meant that I also needed to do a quick hop between tmux windows afterwards to render and clear up the screen to see my code. 

So I went looking for a remedy. At first I only came across forum threads patiently describing how this wasn't a technology for virtual desktop computing, but through some search I managed to find some [Linux VM tools from Microsoft](https://github.com/microsoft/linux-vm-tools) and instructions for enabling XRDP connection to the VM. 

Happily I chugged through it, rebooted, chugged some more, rebooted again, and got the XRDP VNC login greeter form. Great success, or so I thought. 

There was one pretty obvious problem, logging in dumped me into the fairly hideous Ubuntu Unity desktop environment instead of my prefered and tailored i3 setup. 

Panicking and revulsed I fumbled out a terminal and ripped out the line containing 'unity' from the .xsession and promptly entered 'i3wm' instead. 

Quite the mistake. 

What happened after reboot and entering my credentials was a sudden death of the XRDP connection. Over and over. It took me a little bit of patiently retrying while thinking about the issue to realise my mistake. 

The i3 binary isn't named i3wm, hence the .xsession script crashed and burned on login, killing the XRDP connection. 

After some thinking and reading up on `help Set-VM` in Powershell I figured out how to turn off XRDP on the Windows end, dropping me into the LightDM greeter instead, and also realised that I could just SSH into the machine to edit the .xsession file. So I did the fixing thing, and a few reboots later it had also been rudely pruned of all the rest of the preinstalled Unity-related calls the .xsession file had been cursed with. 

Compared to the basic Hyper-V VM-connection XRDP is really snappy and almost entirely free from weird graphical artifacts littering the screen every now and then. I had to change the terminal font to make it render better and be more easily read but other than that i3 just worked and pretty good too. 

If you are in a similar situation but haven't found that Github repo yet, go there and try it out. Just make sure your VM boots up to sshd being started (and reachable over your network or virtual switches) so you can [PuTTY](https://www.putty.org/)-rollback any mistakes while axing the defaults those scripts install for you, just in case you manage to break the LightDM config and get locked out from that one as well. 

The commands for switching connection modes on the Windows end are these, to turn XRDP on first, off second:
```
PS C:\Windows\system32> Set-VM -VMName your-vm-name-here -EnhancedSessionTransportType HvSocket
PS C:\Windows\system32> Set-VM -VMName your-vm-name-here -EnhancedSessionTransportType VMBus
```

Powershell probably needs admin privileges for it to take effect. It should always have, to keep the chance open of bricking one's Windows system and getting an upgrade to something unixlike. 

Other than this we also run some source control and keep remote repos, but that's rarely something one can decide as freely over as whether to suffer under the PHPStorm colossus or integrate oneself neatly and elegantly into a guest operating system with tmux-vim-ripgrep in WSL or Hyper-V. 

Oh, and as a royal grande finale, here's the regedit you need to run to switch Caps and left Ctrl:
```
REGEDIT4
          
          [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
          "Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,1d,00,3a,00,3a,00,1d,00,00,00,00,00
```

Figuring that out was severely cumbersome and boring and nasty (and if this hex happens to be wrong, comment and I'll share the other I stored which then is sure to be the correct one). Compared to throwing in a xkbdmap or whatever into one's startup scripts RegEdit is a nightmare. And yes, I know there are applications one can soil the system with that supposedly kind of solve it, but I don't like how they dress so they aren't welcome.