Laravel End to End – Part 1: Tools and Environments

Good morning, good afternoon, good evening and goodnight to you. Thank you for joining me for the second part of this blog series, in which I am going to be talking mostly about tools and environments.

For me, there are several key bits of kit you need as a developer. These tools, I have found, can either help or hinder your work – But if you find the right ones and get into a groove with them, you are generally onto a more productive day.
The tools I would usually list are below:

  • A Laptop
  • An IDE
  • A Version Control System
  • An API Tool
  • A Local Development Environment
  • A Testing Environment
  • A Live Environment
  • A JSON Interpreter
  • Lots and Lots of Coffee!

Let’s start from the top and work our way down the list. I will give you my opinion and way of working, but in all seriousness you are welcome to choose and adapt these methods and tools all you want. We are, after all, each uniquely individual and there is not right set of tools as far as I am aware.


Yep, a laptop. Be that a Windows based machine, a linux box or a Mac. Laptops are more portable than desktops, obviously, and therefore when you’re being stressed out in one room by an irritating noise or incessant chat you can slink off to a dark corner and lock yourself away like a hermit. (Or maybe that’s just me?).

Laptops also help you to work in places where your creativity is at its peak. So, on a train journey is my peak creativity point.


This is a tricky one and depends a lot on what you want to spend for a license. If you’re getting paid for your design work, then I would suggest going in for a more premium IDE. They tend to have more support, more features, more plugins and generally better code completion (although some freebies have excellent plugins – Here’s looking at you VS Code).

The IDE I choose to use is PHPStorm because it is just so damn versatile. It is £7.99 per month, which doesn’t erode my profits too much – plus, because it’s a personal license I can use it across several machines if I want to, for any project I choose.
PHPStorm offers a really intuitive interface, giving you keyboard commands for most anything you will ever need to do. It is also based solely around PHP and therefore builds in a lot of the core standards for PHP out of the box (PSR1/2 Compliance is just a tickbox away).

There are, however, more choices than just PHPStorm for code editing. You may choose from anything from NetBeans, Aptana, Eclipse, ZendStudio, and even Microsoft Visual Studio Code. This is your personal choice, but I would highky recommend PHPStorm for its sheer amount of built-in features.

A Version Control System

So, for me working as part of a team, it has been a stark contrast to the version control I was used to as a singleton developer. Previously, I had one master branch and one develop branch. I would make my changes to the develop branch and then merge into the master branch for deployment.
This has changed somewhat in that now the develop is the main branch we pull from as a team as it incorporates all of the latest changes, but we create task-related branches. So if I wanted to create a customer search piece of functionality, I would branch from Develop and call it ‘feature/customer_search’. This means that it is a new feature.

Every company does version control differently, but as a general rule of thumb I use Github and Atlassian Bitbucket. These two use the popular Git functionality and therefore comes very easily to the experienced developer.

In terms of tools, I would suggest getting something called Sourcetree for Windows, which will connect you to your Atlassian Bitbucket repositories. With regard the github repos, I generally download github for Desktop, which allows me to directly manipulate the repository from a GUI.

An API Tool

This is what we will need to use to start probing APIs for their responses. These tools are infinitely valuable and can mean the difference between three hours bug hunting and a five minute fix.

Personally, I use Postman. This can be use to define requests and read responses directly. The benefit of this is that you can see immediately what is being returned by each endpoint for the given request body.



This, again, is a wide open topic. I know a lot of developers who use Docker and swear by it for virtualising containers without the overhead of the entire virtualised OS.

Personally, I like to replicate exactly the environment that my code will be working on in a live environment, so that I can see any discrepancies whilst I am developing.

On my local environment I virtualise the Homestead environment, which is the Laravel default requirements bundled up in one package as a single machine specification.

I run Vagrant to manage my images and distros, and I use Virtualbox to virtualise the environment I am going to be developing in.

I usually run a local environment on my machine using vagrant/virtualbox, and a dev/test server on an actual Ubuntu machine. This means that I can see the performance and the look and feel of the website much better than on a virtualised environment.

Finally, I run a live server. Until recently, this used to be always with 1&1, but since they were taken over by Ionos their service and support appears to have gone down the drain and so I have gone DevOps on it and begun a server infrastructure on AWS. This can be tricky to set up at first but the benefits of a speedy server far outweigh the effort needed to set it up.

A JSON Interpreter

This can be a lifesaver in terms of reviewing output in debug and log files. You will often find that the output from each request comes in the form of a JSON Response – This tool helps to make that JSON Response human-readable.

For this task I use a small application called JSON Lint. The small package comes as an extension to Google Chrome and gives you the ability to parse JSON code and really see what is going on.

JSON Lint Interpreter

Lots of Coffee

I would suggest that you get yourself a coffee machine because once you’re in the flow of things you’ll barely want to look away from your screen.

Coffee truly is the elixir of life for coders, but if you really can’t stand coffee then you may like Jasmine Green Tea instead. The choice is yours.


So now that you have your setup ready and you have had a chance to play around with your new found tools, we can start to really dig into the core of Laravel 5.7

I hope you’ve enjoyed this read. If so, then please continue to look out for the rest of my series and join me as I go through Laravel – End to End.

Ciao for now!

Laravel – End to End

Well hello there, Friend. Thanks for dropping by and looking at my blog.

My name is Kayleigh, and I am a web developer! I have been in my current job as a Full-Stack PHP Developer for a popular Boiler Company in the UK for almost a year using Laravel full time. Before that, I have used other MVCs and technologies such as CakePHP, CodeIgniter 2, Concrete5 and even straight PHP to create my own websites and web apps.

This is the first in a series of posts I am producing called Laravel End to End. The purpose of these posts is threefold :-

  • Firstly, I need somewhere to gather my thoughts as I consolidate my understanding and knowledge from the first year of Laravel. This helps me to deeply embed the learning I have done over the past 12 months.
  • Secondly, It will help me to uncover gaps in my knowledge and pose questions about better ways of doing things – A self-critical analysis of my own work if you will.
  • Thirdly, I hope that this will be a resource that others will be able to come to when they are in a similar position to me, still feeling slightly like an imposter in the sheep pen, and needing some reassurance that they’re on the right track.

I will be following the Laravel Certification Exam Preparation Curriculum in my posts, and I expect that as I go along I will find things that I either do not grasp or haven’t even used yet.

A snippet of the Laravel Certification Curriculum

I’m going to be brave and turn on moderated comments on these posts too so that I can have your feedback and hopefully get some of your marvelous experience woven into my own understanding.

I will assume a basic knowledge of HTML, CSS, Javascript, PHP, Linux/Windows Shell Commands and other tools. If you’re not comfortable with these then there are a lot of resources out there for you to look at – This just isn’t a good one to start off with.

So, without further ado, let’s cut the waffle and dive straight in. My next post will be around tools and environments.

Bye for now!