One of the hard parts about learning how to develop software is the minefield of acronyms that exist within the industry.
The goal of this series of articles is to shine a light on an acronym so that the next time another developer uses it in conversation you can follow along without missing a beat.Read More
In PHP it’s fairly common to see the
We run across these all the time and can easily understand what happens when we pass them a
false value. However what happens when the condition of the
if statement is an object, a string, or a number?
Loosely typed languages like PHP allow us to use any kind of variable as if it was a boolean value in our
When PHP needs to evaluate the
if statement it converts our variable into something is can represent as a boolean. Ideally this would be a
false but in PHP it will convert any variable into something it can represent as one of those two values. This is where “truthy” and “falsy” come in. A variable that isn’t
false can be truthy or falsy.
Luckily for us there’s a logical consistency with how PHP type juggles our variables into truthy and falsy. For the most part the logic is that anything “empty” is falsy and anything with a value is truthy.
0 is falsy but
-1 are truthy.
Empty arrays are falsy but arrays with a value are truthy.
Empty strings are falsy but strings with a value are truthy.
null values are falsy.
By default when Vagrant boots a VM it do so in a mode know as “headless mode”. Headless mode just means that no UI from the underlying provider is displayed. There are going to situations where we’re testing changes to our VM and we’ll be unable to access the VM using
vagrant ssh (such as when we make a mistake altering the firewall rules). In order to display the UI we can add
vb.gui = true to our virtualbox configuration.
Vagrant.configure("2") do |config| config.vm.box = "generic/ubuntu2004" config.vm.provider "virtualbox" do |vb| # Display the VirtualBox GUI when booting the machine vb.gui = true end end
The next time we perform a
vagrant up or
vagrant reload VirtualBox will open and we’ll see the virtualbox displayed.
Then we can login using vagrant as the username and password and preform any actions we need to troubleshoot the problem.
What if I told you PHP has a built-in feature that will reduce the number of bugs in our code base? What if I told you it’s super simple to introduce into your daily coding routine? Would you be interested in using it?
In this article, we discuss why we should always use type declarations for function parameters and return values.Read More
This post is the companion piece to my presentation at Midwest PHP 2021.Read More
The Vagrant box that we pick will default to some amount of RAM. During our development, we’ll run into situations where we need to increase that amount. To do that we’re going to introduce a new section that’s specific to VirtualBox. We can then set the amount of RAM (in Megabytes) using the
memory configuration setting.
Vagrant.configure("2") do |config| config.vm.box = "generic/ubuntu2004" config.vm.provider "virtualbox" do |vb| # Customize the amount of memory on the VM: vb.memory = "4096" end end
The fun part about this setting is that because we’re configuring resources for a VM and not a physical device we can easily give it memory amounts that would be hard to get into a physical device. For example, we could give our VM 3GB of RAM.
Vagrant.configure("2") do |config| config.vm.box = "generic/ubuntu2004" config.vm.provider "virtualbox" do |vb| # Customize the amount of memory on the VM: vb.memory = "3072" end end
Now if reload our VM and ssh into it we can check and see we now have 3 GB of RAM.
$ free -mh total used free shared buff/cache available Mem: 2.9Gi 452Mi 2.2Gi 3.0Mi 328Mi 2.3Gi Swap: 1.9Gi 0B 1.9Gi
If you have questions related to vagrant or the PHP ecosystem in general you would like us to answer in future videos please ask them in the comments below.
One of the hard parts about learning how to develop software is the minefield of acronyms that exists in the industry. The goal of this series of articles is to shine a light on an acronym so the next time another developer uses it in conversation you can follow along without missing a beat.
In this article, we’re going to be discussing the acronym LAMP. We’re picking this acronym because we’ve used it a couple of times in other articles and in doing so we have to use other acronyms which we’ll define in future articles. :-)Read More
subscribe via RSS