The barrier of entering the web development industry as a web developer is still low, but it’s getting increasingly complex.
The dynamic nature of the whole industry makes requirements shift often to the most popular and “next best thing” tools and programming languages.
Gone are the days when only one programming language or a very specific process was required from a developer. Nowadays programmers must know a range of technologies across multiple platforms in order to do good work.
What does a full-stack developer mean?
The term full-stack means developers who are comfortable working with both back-end and front-end technologies.
A full-stack developer doesn’t need to master all of the areas and technologies he needs to work it, because that just makes it nearly impossible, he just needs to be comfortable working with those technologies, and that’s a lot too.
What full-stack meant in 2000 and what it means now?
Over the past years I had the opportunity to work on some interesting projects, complex in nature with an ongoing development, constantly upgrading, refactoring and adding new features to them.
This article will cover the biggest coding oversights most PHP developers make, when dealing with medium and large projects. Oversights such as not differentiating between development environments or not implementing caching and backup.
The examples below are in PHP, but the idea behind each problem is generic.
The root of these problems lies mainly in developers’ knowledge and experience, especially the lack of it. I’m not trying to bash anybody, I do not consider myself the perfect developer who knows everything, so bear with me.
In my experience we could categorize these problems in three main groups: design level, application level and database level oversights. We’ll break down each one separately.
Application Level Oversights
Developing with error reporting off
The only question I can ask is: why? Why do you not turn error reporting on when developing an application?
PHP has many levels of error reporting, and it ALL should be turned on in the development phase.
If you think errors will never occur, you are coding for the ideal scenario, which only happens in an ideal world.
Error reporting and displaying those errors are not the same either.
error_reporting()sets the level of errors (e.g. notice, warnings, fatal errors) and
display_errorscontrols whether these errors will be outputted or not.
Error reporting should always be at the highest setting in development:
Note: E_ALL is the highest since PHP 5.4+, because E_STRICT errors became part of E_ALL in PHP 5.4. If you use an older PHP version than 5.4 use
error_reporting(E_ALL | E_STRICT);to include strict error warnings too.
In the first part of this article, we showed you how to create a Vagrant base box, installing the latest Ubuntu 14.04 LTS in the virtual machine to use it as the guest operating system.
In this part you will learn how to setup a development environment using Vagrant, which you can use and reuse in your development. Note that while you can use the box we created in the previous part for the remainder of this post, you don’t have to – this will all work on any Ubuntu based Vagrant box.
The primary configuration location for any Vagrant development environment is a file called Vagrantfile which you need to place in your project’s folder.
The configuration syntax of this Vagrantfile is Ruby, but you do not need to be a Ruby programmer or have any knowledge of the programming language to write this configuration file. You’ll mostly do basic variable assignment in the configuration.
Every configuration option you will need you can place inside this file.
Let’s go ahead and create a test folder called vagrant-tutorial and inside this folder create the file named Vagrantfile so your folder structure looks like this:
The primary purpose of Vagrant is to have a base virtual machine and to give you the framework for creating automatic software installations and configurations in the virtual machine.
By letting Vagrant handle the provisioning of software, it also gives you the flexibility in configuration and more importantly, makes this process repeatable and automatic.
Vagrant doesn’t care how you provision the virtual machine, it offers multiple options ranging from basic shell scripts to software automation managers such as Puppet, Chef or Ansible. You can even configure it to use multiple provisioners at the same time.
Ofcourse there’s always the possibility to vagrant ssh into the base virtual machine and install your required software manually, but that defeats the purpose of Vagrant and all the flexibility it offers when provisioning a box.
Before we can start provisioning the base box, we need to set a few required options in our configuration file.
Vagrant API version
Vagrant uses API versions for its configuration file, this is how it can stay backwards compatible. So in every Vagrantfile we need to specify which version to use. The current one is version 2 which works with Vagrant 1.1 and up. Let’s write this block in our Vagrantfile.
Interesting tools are emerging each day of the year, helping developers work faster, keeping them focused on the actual business values of the project. One such tool is Vagrant, which is becoming one of the strongest helping hands for a developer, standardizing how development environments are created and managed. In this article you’ll learn how […]
Every PHP programmer has the responsibility to understand how attacks can be carried out against their code to exploit possible security vulnerabilities. Reading this article, you’ll find out more about cross-site scripting attacks and how to prevent them in your PHP scripts.