Installing Shopware on WSL

As mentioned in a previous post, I recently upgraded to WSL2 on my laptop. WSL basically lets you run linux and windows at the same time – a fact which still somewhat blows my mind given the MS attitude towards linux back when I first started using Linux…

Anyways, the goal was get to a point where I could install Shopware and start playing around with it. Shopware’s docs point you towards using Docker to set up Shopware for development work, but I’ve not had great experiences with Docker in the past, didn’t think that I had the disk space to spare for that – and looking at Shopware’s “installation from scratch” it didn’t look too bad.

The first step was to make sure my linux set up included all the requirements. I’d chosen to install Ubuntu 20.04 under WSL2, so the main things I needed to was make sure I had the right versions of MySQL and PHP installed. PHP needed to be updated to 7.4, as Ubuntu had come with 7.2. A couple ‘apt’ commands and that’s taken care of, and then I had to tell Apache to use PHP 7.4 rather than 7.2 – and also had to update my Apache config as indicated in the documentation.

I also had to install Node and NPM, again just simple apt commands and then it was time to check out the Shopware code from github and try running the setup script.

This is where I ran into minor problems. I got the cryptic “could not find driver” error and it took a little googling to realize that my new version of PHP was missing a few modules, including the driver to connect to MySQL. I found that running ‘sudo apt install lamp-server^’ took care of a lot of these and some googling tracked down the other packages needed.

Time for WSL2…

After more than two years running WSL (Windows System Linux) on my laptop I’ve finally upgraded to the new version. Honestly, the old version was working just fine for me. My understanding is the new version’s primary benefit lies in performance increases and I think better Docker support.

My experience with Docker has been… awkward, to say the least. I’m in no hurry to go that route if I can possible avoid it, so that’s not why I’ve upgraded. And the sites I work on are quite efficient, so performance on my dev laptop is not a big issue.

I decided to play around with Shopware a bit and ran into problems trying to get it working under WSL1. Those problems may have nothing to do with WSL1 but it seemed possible, and I kind of thought that there’d be performance issues anyways, so here we go.

I’d been leery of this update because my current dev setup relies on it, and I didn’t want to have to go down some rabbit hole to get back to square one if things went wrong. Well, it went quite smoothly! I followed the instructions here and had only one pretty minor hickup.

It went like a charm until I decided that I’d like to mount my project directory into the new Ubuntu “server” I’d set up. Turns out you don’t get the “mount” option unless you’re part of the windows “insiders” program or somesuch. Oh well, the only reason I wanted to use WSL2 was to install Shopware, which doesn’t require mounting my old projects directory so no worries!

Also, you can quite easily switch between WSL1 and WSL2 – so I can just “switch on” whichever one I need for the work that needs doing. Cool!

Now to install Shopware, which is a whole other project.

Tech and Terminology and Political Correctness

I usually don’t post anything too political on my blog – that old saying about politics and religion is a very wise one – but I thought I’d weigh in on a debate going on in the tech world regarding some of the terms we use, and whether they should continue to be used.

In the aftermath of George Floyd’s death and associated protests and turmoil, a lot of attention has been put on many terms and symbols that are perceived as carrying racist overtones or baggage.

To be absolutely clear, I complete support black lives matter and think the vast majority of these protests are completely acceptable and necessary. This country has a lot of things to issues and racial problems are part and parcel of our history and the texture of this country. Segregation only ended in my parent’s lifetime – and we finally got gay marriage only very, very recently. And I’ve always wondered why we would have statues and military bases named after literal rebels and traitors.

In the tech world there’s a lot of discussion about changing some terms that we use – such as blacklist/whitelist and master/slave. For blacklist/whitelist I think changing it to something allow/block list or something along those lines makes a lot of sense. Think about it, I don’t think the term itself is overtly racist – however the negative/positive associated with black/white is problematic. More importantly, these are not clear terms! Allow/Block is far clearer, in my opinion.

Master/Slave is another pretty problematic term. It is descriptive of the relationship, however in most of the world the idea of a “master” will construe as white and “slave” as non-white. That’s just the reality of the world. Yes, I know there have been all kinds of slavery throughout history, some with racial overtones and much without. I was a history major! But that’s irrelevant – what matters is what makes sense to the majority of people alive now. I’d suggest something more like Source/Duplicate, or Original/Duplicate, etc. I think that still describes the relationship well, at least for a database setup…

But with Master Branch (i.e. in git) I’m not sure there’s the same racial overtones. For one thing, we don’t call other branches “slave” branches, and if we did it wouldn’t really capture the relationship well at all. A branch off master is not “controlled” or “dominated” by the master in any way, typically. Honestly, something like “trunk/branch” might make more sense, but a lot of this depends on how you use git. I just don’t see this as a problem as bad as say the “master/slave” terms!

Likewise, Master Repository has the same issues as above. What’s really being described is more like “original” versus “branch” or “derivative” etc. It doesn’t seem like that much of a problem – but it shouldn’t be hard to find a less controversial term that also accurately describes the relationship.

I guess I’m generally in favor or trying to change usage of these terms – as long as another term can be found that describes the relationship at least as well. But I also think that like most things they’re on a spectrum from more “racist” (black/white list) to less.

But, another aspect of this whole controversy should be kept in mind – arguably the organizations who are making these changes to their terminology could be helping things a lot more by becoming diverse and inclusive workplaces. I’m not saying that they’re not! But I am saying that we shouldn’t let this little debate over terms distract from more meaningful changes.

New Windows Terminal

Just updated windows so I could install the new windows terminal – and I’m quite impressed. It’s noticeably faster than what I was using before, and seems like it’s quite configurable. I spend so much time on the command line that I sometimes forget I’m even using windows.

You can install it via the windows store. I had to update windows to meet the requirements.

Next up, install WSL2 which I’ve heard many good things about. I might wait a bit on that one, because it seems much more likely to throw a wrench into my current dev setup and make me burn a lot of time to fix… but the benefits sound great.

WSL & LAMP part two

As mentioned before, I’m restarting my windows-based LAMP developer experience after a long sojourn in MacOS. This post is meant to look at where I am a few weeks in, and tips/tricks/problems I’ve encountered. I’ll probably post a review of the actual laptop I went for later.

All in all, the experience has been quite good. I have a full LAMP stack set up and running well, with very few hiccups. Right now I have it set up to run three different sites, two custom PHP and one that runs mostly off WordPress. All I have to do to change which site I want to just off of http://localhost is edit the relevant Apache configs and restart Apache.

I’m a vim user so I haven’t needed to install any big clunky IDEs. I do have sublime which I mostly use as a giant clipboard/notes app. Everything else lives in Trello or Google Sheets, or Slack.

I did have some odd issues initially running my linux terminal – until I got used to it. I just had to get used to opening new terminal windows from within the linux app. The only other niggling issues are that you can’t seem to split the screen (something I do very rarely anyways) – and sometimes when pasting a large amount of text within vim, there’s a slight delay. That’s all!

So, all in all I’ve made the transition quite seamlessly – maybe a day or so of lost productivity while getting everything set up and moved over from my old mac.

Running Linux in Windows

I wrote this post about two weeks ago and apparently forgot to publish it… so publishing it now as a prefix to another post that will explain my new windows-based linux setup (what a weird sentence that is!)

It’s been said before, but what a weird time we live in!

As mentioned previously, I finally had to ditch MacOS as my main work OS, thanks to new machines just not matching the price and functionality (and reliability) point for me. And haven’t been a fan of the changes they’ve been making to MacOS over the years anyways…

So, I’m on day three of my (resumed) Windows journey. But, I’m a web developer primarily in the LAMP stack, and I know that I can’t just set up a dev environment within windows for that, when everything I create is hosted on Linux…

My original plan was to just set up a virtual machine in Windows and just work within that. But, thankfully I remembered that there’s now WSL (Windows Subsystem for Linux) that could be an option… and so far, so good!

WSL lets you run linux within Windows, without the need for a virtual machine, or Docker or whatever. Basically, one it’s set up – you can have a bash prompt – and once you have that, you can install all sorts of things you need to do your job efficiently.

I’m not going to go through the whole process because there’s plenty of good guides out there – I’ve linked to a few at the bottom of this post. Instead, I’ll focus on a couple of the gotchas that held me up as I was getting everything set up.

File Permissions
Once I got the LAMP stack up and running, I grabbed all my files off my old macbook and set them up on the new laptop. But, the first I ran git status it told me every file had changed. Great, that’s not a good sign! My first thought was the old issue with newlines – but that’s not an issue using WSL since you’re inside linux anyways… Turns out there’s some file permission weirdness, and all of my files now had 777– and git thought I wanted to change all those files’ permissions – probably not a good plan! Turns out setting a simple git config option to ignore permission changes took care of that problem:
git config core.filemode false

Getting a Decent Terminal
You can use the built-in windows terminal… and it certainly is leaps and bounds better than last time I used Windows (*cough* Vista) so there’s that. I should probably explore it more.

I tried a few other terminals recommended in one of the guides, w/mediocre results. Some felt slow. And many of them had problems recognizing the arrow keys in vim – I can get by without them but I tend to alternate between the arrow keys and other options when moving around in vim without much though, so having the arrow keys suddenly not working was jarring.

For awhile I was using the Hyper terminal because it looked good and handled arrow keys just fine – but it felt a little slow and had the occasional weird glitch. I guess it’s built with javascript/css, etc which is kind of cool. But, contrary to popular belief we do not have to use javascript (of all things) for everything under the sun…

So, I followed this guide to set up the linux xfce terminal, running via X. I was a little leery at first, flashbacks to my early linux days with X (think pre 2000) but of course things have gotten much easier since then! I’ve gotten it all set up and about to embark on a work session with the new setup – we’ll see!


git and the single dev

I’ve returned from (arguably) the last Magento Imagine and have almost recovered from my personal branch of the flu that seems to have been burning through the attendees. While hacking and spluttering and read Reilly Chase’s post on using git as a solo developer and thought it was a great idea for an article.

I think I started using git about 10 years ago (geez) and at the time was acting as solo dev on most of the projects I worked on. It seemed slightly useful, but honestly seemed like a lot of overhead for not much benefit. I already had my own system of local backups that I was quite comfortable with.

But, git was “how real developers worked” so I started to use it. I set up a remote server to use as my remote repo (didn’t use github at first) and had relatively few problems using it locally – but I was paranoid about running it on the live server. It seemed like one flubbed command could really mess up the site!

So, at the time I installed the repo outside of the web root on the live server, and manually copied changed files from there to where they needed to go. Obviously not the most efficient way to do things!

Eventually I moved on to managing a pretty large open source project on github, and quickly began to learn the value of git in the multi-developer context. And once I became a developer working with about a dozen other devs on projects that used an entirely git-based workflow, it was clear how critical a tool git is for multi-developer projects.

But, what about the single dev?

Beyond the obvious advantages of using git (branching/merging/etc) there’s a few others I’d like to highlight

  • Detecting changes on the live server – if site is running from the repo on the server, a single git status command will show you changed files or new untracked files. Very handy in cases where an attacker has gained access to the server!
  • Remembering what you did last – there may be big gaps of time between when I work on a client’s site – while waiting on feedback/payment/etc. A quick git log shows the recent commits. Or look at github/bitbucket to see what you were up to. This is also a great way to reconstruct work done on a site for billing purposes, if you forgot to log your hours :\

My strategy

I generally keep my workflow pretty simple. Almost all work is done locally in MAMP (I mostly work on LAMP stack sites), tracked within a single master branch. I use Bitbucket for my remote. I do occasionally create a branch if I’m messing around on something I think I may need to keep around longer term – best example was working on converting an older site to use PHP7.2 – while ongoing work was going on in PHP 5.6.

On some more complex projects, I have a staging server set up to allow the client to see changes before they go live. This is usually a cheap Lightsail instance. I set up the repo containing the site files there, and just do a quick git fetch when I want to see what updates will be applied, and git pull to bring them down.

The live server is set up the same way. I always do a fetch first to make sure I know exactly what’s going to be pulled on to the live site. No surprises!

I realize I could use hooks or something to have the live server automatically update when I push commits to master, but with my setup that doesn’t make much sense – I prefer to do this manually. And as I mentioned, running git status on the live server now and then gives me one more level of security check… I do have one project moving towards an architecture of multiple front end nodes, in which case I will have to change this model. In that case, I don’t want to have to login to each node to pull down the latest commits. A bridge to cross when I get to it!