In your application, every time you call an "external" service you are vulnerable to the failure in that service. That either might be a third party API being down, your database being unresponsive or unexpected errors from the 3rd party library you are using. With many developers and companies being interested in composing applications out of microservices at the moment, guarding for failures because of broken dependencies gets even more important.
If you're familiar with Composer you know it can be slow and sometimes unreliable when one or more packages are not available.
Once in a while I think about profiling my web applications to see if I can get them to run faster. There are cool tools out there like XHProf and XHGUI to help you do exactly that. And then I remember it took me quite some time to get it all set up... But now that I've started using Ansible I decided to document the set up process and share it with you. Today I will walk you through my Ansible role for setting up everything you need for profiling your first PHP script.
In my previous post I introduced you to Ansible. I showed you how to install Ansible, how to create a server inventory and how to execute some basic commands. Afterwards we installed a very basic web server with PHP and Apache and we ended up with a working Hello World script.
In this post I will show you how to organize your server configuration using playbooks and roles. As an example we will install MariaDB 10.0 beta.
I remember having to install a new web server next to an existing one. The only requirement my boss had was it had to be "the same" as the existing one. There were two problems:
- no one had ever documented which packages were needed to run our software
- the existing server hadn't been upgraded in ages.
I had to use trial and error to get the new server up and running and still I wasn't confident everything was properly installed. What I needed at that time was a way to manage my server configuration.
In this blog post I will tell you about my experience with server provisioning, why I chose Ansible and I will show you how to install a web server.
In the previous parts of this series we got you started with HHVM and showed how we could get the symfony standard edition running on HHVM. This time we will dive deeper into HHVM by using it to debug our application.
For most people the easiest way of debugging a PHP application is to place
die() statements all over the code. Another option is
installing xdebug, which has gotten a lot easier nowadays due to IDE
In this blog post we'll show you how to debug your PHP application using HHVM. We describe how you can step through your program, set and manage your breakpoints, how to inspect variables and take a peek at helpful features like conditional breakpoints.
In part one of this series we talked about "Getting started with HHVM" by getting a compiled version of HHVM running in a vagrant box. In this part we'll configure the HHVM webserver to run the symfony standard edition.
Facebook deploys one of the biggest PHP codebases in the world. They’re not only pushing the boundaries of what you can do with PHP, but also PHP itself. A few years ago they open-sourced their hiphop compiler and nowadays facebook.com runs on their latest generation of the HipHop Virtual Machine (hhvm).
HipHop is Facebook's complete toolchain for the PHP language: interpreter, JIT compiler and debugger.
Facebook.com was motivated to create HipHop to save recources on their servers. They claim to be 40% faster than their previous version that was in fact a PHP to C++ compiler which was already faster than plain PHP 1.
In this blog series we’ll get you started with hhvm. We’ll get the symfony standard edition running and show the ins and outs of debugging your code with hhvm (which is awesome!). Today, we’ll start of by setting up hhvm in your own vagrant box.
It's "official", our development team now has a blog. At Qandidate.com we spend one day a week on research and other fun stuff that's not related to our short term roadmap. We use this time to check out new techniques, build prototypes and educate ourselves on current 'cutting edge' technology.
In order to capture the things we learn during 20% time we've been blogging on an internal blog for some time now. A short while ago we decided we wanted to share what we've learned with the world and so this blog was born!
In the future we'll blog about all things PHP, our development process and all things development which aren't really PHP. Stay tuned!
In the meantime, enjoy one of our favorite cat gifs!