5 years working at Openhost: from craftsmanship to enterprisy

Making a quick pit stop to mark this milestone in my professional career: today is my 5-year anniversary at Openhost! Time has certainly flown by and I really cannot believe that it has been five years since I joined this company.

I know it is sort of cliche to say “I can not believe that it has been this long…” but it is so true. Back then I joined a relatively new project built particularly for a client that we wanted to get a proper SaaS from it, and the first few months had me digging out in the foundations of that monolithic software, trying to learn all how to handle thousands of requests per minute for the existing no-framework “crappy” code (now we are fully, and happily may I add, using one of them).

I did a lot of researching and development for sure, and through the next months, through many long days and nights, I succeeded in improving, going from a Senior Software Developer, to a Supervisor of the team, to eventually becoming the Manager for the entire development team. I worked really hard, but I have worked just as hard before in previous places! Changing so many parts of the initial project, and rebuilding from scratch key components one part at a time while getting profit from the project in production was a huge and hard thing to do. And I can not deny that I was a little overwhelmed at first because everything was on my shoulders, but with our amazing team I think that we reached the goal.

The best part of being an Openhoster for 5 years? Being able to learn to change the tires to a car while driving at 300 km/h, having side-by-side the increasing family of  “OpenHosters”, exciting people who not only enjoy what they do, but are always willing to get the best from themselves! There is not a single day that I don’t learn something new, and thankfully I don’t see any sign of this trend stopping :) Getting up in the morning and walking into my home office (yeah, they let me work remotely), is never a drag because I just know that there are ‘achievements to unlock’ right around the corner and OpenHost let me tackle them the way a I want.

I am OpenHoster!!!

Easy way to install PHP QA tools

If you need an easy and quick way to install your PHP QA tools, you can use the next bash snippet.

# Install composer based tools
cat > ~/.composer/composer.json <<EOF
    "require": {
        "halleck45/phpmetrics": "@dev",
        "squizlabs/php_codesniffer": "*",
        "phpunit/phpunit": "*",
        "sebastian/phpcpd": "*",
        "sebastian/phpdcd": "*",
        "phpmd/phpmd" : "@stable",
        "pdepend/pdepend" : "@stable",
        "phploc/phploc": "*",
        "sebastian/hhvm-wrapper": "*",
        "theseer/phpdox": "*"
curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer
/usr/local/bin/composer global install
chown -R $SUDO_USER.$SUDO_USER ~/.composer

And all your required tools (phpunit, phploc, phpmd, pdepend, …) are now located at ~/.composer/vendor/bin, so set your $PATH environment variable to include it.

If you find it useful please share it.

Scale out vs Scale up

There is no doubt that cloud hosting is taking its place and it offers some advantages for managing your deployments but, is it the right choice to take?

This dissertation comes from the recent new that StackOverflow uses a scale-up methodology to handle its services. And that’s a quite strange thing to see nowadays. Every single web service tends to use Scale-out and that’s the same for our company services, OpenHost, where we have been migrating from metal-servers to the cloud “panacea”.

Our main aim to move to cloud servers was to reduce our costs when our infrastructure is not having a lot of load, which always use to be at nights, and to quickly replace malfunctioning servers with new servers by provisioning them with puppet.

Just to clarify the terms, below I will describe both:

  • Scale-up: it is as simple as adding more computational power and RAM to your server, by buying a more expensive and robust server.
  • Scale-out: Refers to adding more servers with less processors and RAM.

There are common pros and cons for scale-up and scale-out which are:

  • Scale-up: they are less challenging to implement, and given that they can use all the power of the “metal” you will retrieve far better performance from the same machine in cloud. As a counterpart, using metal tends to be a risky business due to greater risk of hardware failure that causes bigger outages (yes we have learned this by heart).
  • Scale-out: as the opposite solution, using cloud based solutions tends to be easier to run fault-tolerance and easy to upgrade, but it will have a bigger footprint which raises some doubts about scale-up being harder to implement.

Scale out is usually cheaper overall and can literally scale theoretically infinitely (although we know that there are usually limits imposed by software or the environment’s infrastructure).

Our experience says that you will need more servers due to the fact that those VMs will have far less performance against metal-ones, but they have helped us to autoscale when our infrastructure had a huge demand. And we have mitigated a lot of outages caused by server failures.

A good resource to read is the Scalability Rules: 50 Principles for Scaling Web Sites which explains in a good way how to handle with this problem. But again, it’s quite weird nowadays that services like StackOverflow uses the scale-up technique, but they have probed that this have been worked better than scale-out for them.Take a look at how the StackOverflow was back in January 2014.

Simplified version of my PHP test runner

In my course of getting continuous testing in practice I have improved my test runner by using less dependencies.

Previously I have implemented this by using Ruby and its Watchr gem, but now this script only relies on inotifywait binary available in major distributions.

As usual this script helps you to track your code for changes and if changed it will automatically run a bunch of actions.

We all tend to assume that other people think like us. But they don’t. Psychologists call this the false consensus bias

Giles Colborne in “97 things every programmer should know”

Page 1 of 23