DEV Community: Martins Fridenbergs

PHP development on Win10 through WSL2, Laravel Valet and Tighten Takeout

Martins Fridenbergs — Fri, 27 Nov 2020 09:04:23 +0000

I've been doing PHP development professionally for pretty much the last 10 years. I've also been a Windows user pretty much forever. Put together that has not been the greatest experience as when it comes to running a local webserver the experience has always not been excellent. Nuances like Windows line endings always cause issues. I've tried switching over to Linux but the GUI has always felt like it has lacked. I've never been a fan of macOS but the tools they have like Laravel Valet have made me jealous a fair few times. Thankfully Win10 has WSL2 nowadays which is a game-changer.

This guide explains steps how to set up a PHP environment for local development using Laravel Valet Linux and Tighten Takeout tools on Docker.

WSL2

First of all you will need to set up WSL (Windows Subsystem for Linux) on your machine if you haven't done this already. The official guide for doing this can be found here

Whilst the linux distro used is purely personal preference I've used Ubuntu as it is very widely used and always has good documentation / search results for any issues on web.

Whilst most of the environment will be set up on WSL with Laravel Valet, it does not automatically set up database engine to allow users selecting their own preference. For this reason we will be using Tighten Takout to set up any necessary engines like database / cache / search etc.

Docker

First of all if you don't have docker installed - it is a simple install process to get started. After you set up docker you want to check and ensure docker uses WSL containers - guide to verify and adjust can be found here

Setting up environment

Now that we have pre-requisites installed we can set up the environment.

Update package lists

sudo apt-get update

Install php, its modules and unzip on system

sudo apt install unzip php php-cli php-fpm php-json php-intl php-common php-mysql php-zip php-gd php-mbstring php-curl php-xml php-pear php-bcmath -yqq

If you need any other module you can install it via sudo apt install php-module command. If you require a specific php version or php module version you can use php7.4 php7.4-zip format.

Install composer

curl -sS https://getcomposer.org/installer | php \
            && sudo mv composer.phar /usr/local/bin/ \
            && sudo ln -s /usr/local/bin/composer.phar /usr/local/bin/composer

Prepare for Laravel Valet

We have few additional dependencies to install:

sudo apt-get install network-manager libnss3-tools jq xsel

Also edit /etc/wsl.conf to add following lines. This is nescessary as WSL normally does recreate /etc/resolv.conf file when you start it. Adding this line in wsl config will prevent it from re-writing file as long as the file is not a symlink

[network]
generateResolvConf=false

Install Laravel Valet Linux & Tighten Takeout

composer global require cpriego/valet-linux tightenco/takeout

We also want to make sure we can use commands like valet or takeout without specifying path so we want to make sure that the path to these binaries is registered as part of the system PATH variable. This can be added by updating the ~/.bashrc file by adding the path to global composer bin path.

export PATH=~/.config/composer/vendor/bin:$PATH

Once file has been updated you can reload the bash shell for the new path to be loaded by running source ~/.bashrc

Now we can install Valet.

valet install

This will set up Laravel Valet on device. Valet does change the /etc/resolv.conf file to a symlink which is going to be reset after WSL gets rebooted even with our wsl.conf file edit if we leave it as a symlink. Due to this it is recommended to copy the valet resolv config over.

sudo unlink /etc/resolv.conf
sudo cp /opt/valet-linux/valet-dns /etc/resolv.conf

An issue I've also noticed is that valet linux does not include default DNS config which can cause issues with accessing anything on web from the wsl (including composer installs, pinging and other actions). Due to this it is recommended to add /opt/valet-linux/dns-servers file and have following in it

nameserver 1.1.1.1

1.1.1.1 is Cloudflare DNS, if you don't want to use it you can use 8.8.8.8 for Google DNS or any other alternative.

Starting Services

valet

Now everything should be set up and you should be able to get things started with valet start command. In personal experience I've noticed that php-fpm on ubuntu tends not to start with valet linux and I'm yet to figure out why, but this can be bypassed by running sudo service php7.4-fpm start (or your php version) after starting valet.

Valet also requires you to park a directory to identify where to look for sites. Run valet park in directory where you are locating your projects.

Takeout

Running takout enable should bring up a menu allowing to enable specific service - mysql, postgres, redis, elasticsearch etc. Enabling these will set up a docker container that will be used to manage the service. Services already set up can be seen running takeout list and started/stopped running takeout start CONTAINER_ID and takeout stop CONTAINER_ID

NB Services are available on 127.0.0.1 not localhost so make sure you update your environment variables to reflect this.

Additionals

Node.js

Node.js won't be installed by default, you can run install for this. I've also included npm, however yarn is also a popular package manager that can be used as an alternative to npm.

sudo apt install nodejs npm

I would recommend installing NVM (node version manager) as it allows easily switching between node versions which might come in handy if you need to support some legacy projects. It also could make it easier to upgrade when new version is released

Request routing / DNS

The last thing to get sites working is the requirement to add dns entries for your local pc to route the site to 127.0.0.1. This normally is done in C:/Windows/System32/drivers/etc/hosts file where you specify the domain name and its IP address

127.0.0.1 mysite.test

This is a relatively large set-back when you compare it to the ease of valet on linux/macos where wildcard DNS routing is possible as it requires managing each site individually.
There is however a potential workaround if you are using Chrome as your development web brower. As per IETF specification *.localhost TLD is outlined to be a loopback domain and it should route back to 127.0.0.1. This is however for web browser companies to implement and there are mixed results. From my own testing I've found out that Chrome does support this functionality whilst other browsers (Firefox / Edge) do not do this. So if you primarily work on this browser you can switch valet domain to localhost and it will remove necessity to manually add dns entries.

valet domain localhost

Jack of all trades vs master of one

Martins Fridenbergs — Thu, 06 Feb 2020 16:59:11 +0000

No matter how we'd like to argue at the end of the day there are two types of people - those who are experts in one (relatively) narrow field and those who are capable/good at doing a lot of things but they don't shine in any.

During school we are taught generic education - they throw everything at you from literature, art to math and physics. By the time we get to university we start getting specialization. You already have some of the subjects fading away and with each year you get narrower in your field. This specialization happens also in programming - and it might seem a bit more subtle than you'd think at first. But it slowly creeps in day by day.

I've been meaning to expand my view on programming, try new things and learn a new language. And in this decision I found myself in a very much stuck in my narrow skill-set. You see - after spending 10k hours working with web, working with PHP, working with Laravel-like platforms I've trapped myself in thinking in certain directions, always thinking about certain issues.

I like learning by doing, code by building a prototype solution. For web its easy - I already have 5 ideas in my head for what I want to do and once I start pulling on one it tangles itself into another 5. But trying to do something else, something I am not familiar with, appears to be a lot more difficult. It is not only difficult to formulate the concept, but on top of it it is in a new language with new techniques, new processes. Every step comes slowly - even the point of setting up the environment to start writing code appears to be a lot trickier when its not something you've spent years to optimise.

It might seem better to be on the other side of the table. But its not - whilst having wide general knowledge is good, it is very limiting. Not only job opportunities will be more difficult because expert will do the job better but balancing this status quo in long term is very difficult.

In fairness I do believe that being a master of one field is a lot better than being jack of all - at least in long term. You just need to remember to try something else and different now and then.

Old school developer vs new school developer

Martins Fridenbergs — Sun, 02 Feb 2020 10:24:16 +0000

Every language has its quirks. PHP has been know to be a language where it is very easy to do things badly. In reality it is not the languages fault but how we as developers treat it. Being a lead developer and seeing new employees (and candidates) in action has shown me that there are two types of PHP developers - new school and old school, each with their own issues.

Old School Devleoper is one that has been building functionality for a long time time (obviously). He/she started doing this before the advent of frameworks, most likely even before Composer was a thing. This is a person at whose CV you'll look and consider for a senior level position. But it is not always as great as it looks.

Some of the main risks of the old-school developer:

old habits die hard - the longer you do something, the more you get used to it. It becomes hard to adapt to new techniques, new technologies and even new coding styles.
if the person is not driven to keep improving the code will be functional but more costly. Features will be built from scratch instead of using a library loaded from composer. Templating will be built manually (and will likely include a risk for XSS vulnerability) instead of using an existing library like twig / blade.
harder adaptation to new frameworks and languages.
ego - after doing something for a long time developer will get the confidence of the approach. Whilst not bad on its own, this can cause issues when task is misunderstood or the approach/code does not follow the company's overall guidelines. Also can struggle with having respect for co-workers.

Some of the strenghts of old-school:

usually a strong understanding of tasks and how to build it.
strong time estimation skills.
understanding of vulnerabilities and how to avoid security issues.
usually some dev-ops experience.
good patterns for analysing and debugging. Doesn't go in circles but knows where to look for issues and how to find them.

New School Developer is one that has started web development in the "green days" of PHP. These developers will likely use one of the major frameworks/platforms (Laravel/Symfony/Wordpress/Magento etc.) and will be a powerful tool in your company's arsenal as long as they don't have to step of the comfort of their knowledge.

Some of the main risks of the new-school developer:

Knowledge is usually tied to one framework/platform. Likes to avoid and often shows negative attitude to other tools available.
With frameworks like Laravel handling large amount of sanitation (through templating & PDO) is likely to not know to deal with security risks as they are always handled by the framework.
Usually has less experience and can lead to functionality not matching requirements perfectly or required time may be underestimated.

Some of the strengths of new-school developer:

Knows a framework very well and prefers usage of external libraries to build functionality quicker.
On overall can be quicker as doesn't need to build functionality from scratch, knows the tools and doesn't consider security on every step taken.
Is more fond of the new techniques like Test Driven Development and package building.
Can bring a new and fresh perspective into a company.

So with these two contrasting developer types which is the right one? That largely would depend what kind of developer you need/want to be. For what I've seen in my work there needs to be a mix of both. Old-school developers can achieve this by encouraging new technologies, "keeping the finger on the pulse" to ensure they don't settle into their ways too much. New-school developers need to encourage diversity of frameworks, learn not only about what they are skilled in but also branch out into other frameworks/platforms.

P.S. Where do I consider myself in this? I would probably call myself an old-school developer by heart. But to ensure I don't settle in too deep I spend a lot of time deep-diving into frameworks like Laravel and its underlying Symfony features. I build complex functionality like search filters and shopping baskets in vue.js. I try to ensure I keep learning and growing my skill-set.

Hello Symfony QuestionHelper, hello undocumented features

Martins Fridenbergs — Thu, 30 Jan 2020 15:09:47 +0000

TL;DR - everyone is bad ad documenting functionality under the assumption that it is obvious.

Over the last 2-3 months I've been (passively) looking for a piece of functionality in Laravel artisan console conversation tools - ability to ask a choice question with multiple answers. This hasn't been a priority, but something I've kept noticing and wondered why it isn't there.

Background - I work in a web agency and a large point is the ability to start a new project quickly and efficiently - we are using a plug-and-play module structure and ability to install modules during initial project setup stage is a good feature to have. We already have a list of modules available from an API endpoint, so key aspect is to select ones you want. So what I want to achieve is a list of modules where you just navigate through with arrows and tick the ones you want to install.

First attempt (few months ago) - Laravel has choice() method where you can pass options and select which you want. But no mention of accepting multiple values in documentation and for some reason I've learned to gloss over function attributes from 4th onward. Tweeted asking if anyone knows about a package that does this and shelved it.

Second attempt (few days ago) - started looking at this again and noticed few things. First of all - Laravel Command is Macroable so nothing stops me from building up a multiChoice() method and injecting it into the Command class. But I also noticed that choice() 5th attribute is $multiple. Tried it out and indeed, if I enter the options 0,2 they come up, yay.. or maybe not. Having to enter the options manually feels slow and maybe could be improved?

Third attempt(today) - ok, without further inverstigation I wanted to start playing around and build up the multiChoice() method. Laravel side is easy - with Marcroable I can quickly inject a method inside Command. The tricky bit comes down to how underlying input processing will work (this most likely would mean creating a pull request to Symfony project repos which actually makes me excited).

Having done a few js framework installs and seeing how they tend to handle "checkbox" options in console I already imagined of handling space bar keystroke in multiple question scenario. Started diving through code until was inside Symfony QuestionHelper class. Strarted mocking around, quickly got to the point where I knew what I would need to do, but then I found out that the functionality I was looking for already existed via tab character instead of space. However it's not as intuitive as I'd like, so I'm torn - should I stop and just add a comment for users to understand the usage during usage or should I attempt to build up a functionality that might be declined when it gets to the PR review?

Luckily I haven't spent too much time on this - maybe 2 or 3 hours in total. But these could've been 2-3 minutes if they were documented or made a bit more obvious. I've already submitted a PR to Laravel docs to add information about the multiple choice functionality. I've also learned how important is the documentation of functionality - even the minor details you see as obvious. This is why I'm aiming to revisit the documentation for the functionality my organisation has and ensure it is up to date and detailed.