George Fekete is a web developer with 10 years of experience in client-side and server-side technologies, mainly PHP, JavaScript, working on various mid-sized and large web applications. He is the founder and CTO of Primal Skill, a web development and consulting company in Romania.

George's articles

  1. How to be a Good Developer

    As a PHP developer, or any kind of developer as a matter of fact, you need to constantly improve yourself in this ever-changing industry; you need to learn and use new knowledge every day.

    What successful developers have in common, is that they care about programming a lot, they are professionals treating good programming practices as a form of art.

    In this article, you’ll learn about how to be a better developer by following the “etiquette” of programming and you’ll learn how to use this information to perhaps teach others to better themselves.

    How to be a professional

    Programmer's aid

    Professionalism, regardless of the job you’re working on, always starts with you. Professionals first and foremost have strong personalities and characters.

    As in any area of life, programming professionals are respected. Let’s see how you become one.

    Don’t be egoistic

    I’ve had the chance to work in large teams since I practice this craft and the most important team dynamic I learned early on is that team and collaboration goes hand in hand.

    What you do most of the time in a team is learn from and teach each other, and the work environment should always embrace and reward sharing.

    If you don’t want to share your work and knowledge, you’re arrogant and/or have a big ego, you won’t feel comfortable working in an environment like this.

    Be responsible

    Non-professionals don’t need to take responsibility for their own work. That’s left to the manager. They just get the job assigned to them and forget all about it when the clock hits 5 PM.

    A professional programmer can’t accept this. How would you feel if your bug cost your company thousands of dollars?

    This is a problem of which the solution also depends on management and how the company handles it. Every company should encourage developers to take responsibility of their actions and more importantly of the code they write.

    If your bug slips onto the production server, do everything in your power to fix it as soon as possible, even if it takes all night long. This separates you from the nonprofessionals and gets you a higher paycheck.

  2. Being a Full Stack Developer

    full stack developer

    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.

    To be more specific, it means that the developer can work with databases, PHP, HTML, CSS, JavaScript and everything in between, also, venturing as far as converting Photoshop designs to front-end code.

    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?

    full-stack

  3. 18 Critical Oversights in Web Development

    Oversights

    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

    Error Reporting

    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_errors controls whether these errors will be outputted or not.

    Error reporting should always be at the highest setting in development: error_reporting(E_ALL); and ini_set('display_errors', true);

    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.

  4. Vagrantfile Explained: Setting Up and Provisioning with Shell

    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 Vagrantfile

    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:

    Vagrantfile

    About provisioning

    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.

    Provisioning prerequisites

    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.

  5. How to Create and Share a Vagrant Base Box

    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 […]

  6. Cross-Site Scripting Attacks (XSS)

    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.