VGTech is a blog where the developers and devops of Norways most visited website share code and tricks of the trade… Read more

Are you brilliant? We're hiring. Read more



How I set up my local PHP development environment on Mac OSX Yosemite in three easy steps


When I first started writing this post, I considered giving it a title such as “How to set up local PHP development with dynamically configured mass virtual hosting on Apache 2.4″, “Quick and easy prototyping using Liip PHP, Dnsmasq or Proxy Auto Configuration” or even “The Ultimate Guide to Rapid Development on OSX 10.10″. I did not.

In my daily job as a Development Manager, I don’t get to code very much, but when I do, I want to have a setup that allows me to quickly create development projects and prototypes in the ~/Sites folder and have them show up as vhosts automagically, without having to edit any configuration file(s).

I also want to make sure my pseudo-toplevel domain .dev resolves to localhost and any domains/subdomains i choose to create lead into the relevant web root folder.


Using local packages as composer dependencies


Composer changed pretty much everything when it comes to including dependencies in PHP projects. No more SVN externals or copying large library folders into your project. This is really great, but there’s one thing I’ve been struggling to find a smooth process for; developing dependencies for your project.

When implementing your project, the need for some module, library, service provider or something else will arise, and sometimes you’ll have to implement it yourself. So, how to do that? (more…)

Comparing your privates in PHP


While working with some code that should compare two different instances of the same class I discovered a “hidden” feature in PHP.

I was going to compare several private properties between to objects and started making a piece of code to perform the actual comparison using getters for the properties. I felt the approach sucked, and started looking into alternatives way to do this. (more…)

Swagger docs in ZF2 with examples – Part 2: Swagger UI


This blog post on Swagger UI is a follow-up on my recent post on Swagger annotation parsing in ZF2. If you’re not already set up with Swagger annotation parsing in you ZF2 app I recommend that you read part 1 first.

In the last post we got ZF2 set up with annotation parsing and everything, and the only thing missing was Swagger UI for the neat presentation. I skipped that previosly but today we’ll add the last piece. (more…)

Swagger docs in ZF2 with examples – Part 1: Setup and annotations


So everyone is building APIs now – parsing and outputting JSON is not that hard. Some people even build truly RESTful APIs, or something not to far from that.

Before, when building APIs was about SOAP with XML schemas and WSDL specifications, people spent so much time building their APIs that they had the time to think. Now, building an API is so easy and fast that the documentation is often suffering. Either because not much documentation is written in the first place, or because the API is evolving and nobody takes the time to update the documentation.

Swagger is a popular project providing auto generated API docs based on a service specification. This spec is based on annotation comments in the controllers and models, giving the developer a fairly easy, and close to the code way of keeping the API docs up to date.

In this two-part article on Swagger I will try to cover what you need to get your API docs up and running with Swagger + Swagger UI in ZF2. (more…)

Generating code coverage of Behat tests


Yes, I know, it sounds silly, but bear with me.

The nature of acceptance tests is not really to tests units of code, but to assure that the behavior of your application meets a certain set of criteria (Behat Scenarios).

When your applications grow over time, code coverage can be a nice tool to help you pinpoint where you need to add more tests. In a perfect world tests are added while implementing new features so that your applications are always fully tested, but that isn’t always as easy as it sounds.

This post is a follow-up to Using PHP’s built-in web server in Behat tests that was published some months back, so if you haven’t read that one yet make sure to do so before continuing. If you are not familiar with Behat I suggest you have a look at the quick intro guide as well.


Varnish + HTTP Cache: An intro guide for web developers – Part 1


Varnish, the web application accelerator:


Varnish development was initiated as a project within VG as a direct response to increasing demand hitting our servers hard. Existing caching systems were simply not fast or flexible enough to deal with VGs needs; and so Varnish was born with it’s first official release in 2006.

Varnish is now developed and maintained under a separate company ( It is open source (two-clause BSD license) and used among many large web applications including VG.

Avoid Dependency on 3rd Party Sources With Composer


Composer is the defacto standard dependency manager for PHP out there, also here in VG. We use it for not only our internal packages, but for all external packages like ZF2, Symfony, PHPUnit, etc. For the most parts it has been a pleasant experience, but it creates a hard dependency towards external sources as we now require these sources to be available when updating/installing. (more…)

Inheriting configuration in Zend Framework 2 applications


When working on Zend Framework 2 applications you might come across situations where you need to differentiate the application configuration for the different application environments, be it development, staging, testing and/or production. This can be cache TTL‘s, Memcached hosts, Redis hosts, debugging levels and more.

Instead of copy/pasting the complete configuration across multiple “environment”-configuration files or having switches in the code, like for instance:

Show code
if ($_SERVER['APPLICATION_ENV'] === 'development' || 
    $_SERVER['APPLICATION_ENV'] === 'testing']) {
    // ...

We wanted to use inheritance so that for instance the staging environment would inherit the complete production environment, with the exception of some caching configuration which we want to override in the staging configuration.

This post will explain how we solved this problem in one of our latest Zend Framework 2 applications.


Using PHP’s built-in web server in Behat tests


Behat is a tool for running acceptance tests for your application. If your application is a web application you will need a web server to execute your tests. This is not likely an issue when running your tests locally since you probably have a web server running on the development server that you can use, but when you execute your tests on Travis-CI for instance (you use Travis-CI right? RIGHT?!) it can be cumbersome getting a local Apache up and running for your test suite to use.

Some weeks back I wrote a post showing you how to use PHP’s built in web server in PHPUnit. This post will show you how to do the same for Behat when running your acceptance tests.