Ready for the next version of HTTP?


image credit: O'Reilly

"You will not need to change your websites or applications to ensure they continue to work properly. Not only will your application code and HTTP APIs continue to work uninterrupted, but your application will also likely perform better and consume fewer resources on both client and server."
Source: Akamai

"Although the standard itself does not require usage of encryption, most client implementations have stated that they will only support HTTP/2 over TLS [1.2+], which makes encryption de facto mandatory."

Source: Wikipedia

Resolving git subtree confusion


FYI, there used to be two different git features called subtree which caused a lot of confusion: the official git subtree merging strategy and a third-party open source git subtree script.

As of git version 1.7.11 (July 2012), the script has been merged into the official mainline git (as an optional contrib).

There are also the stree and subrepo projects that are worth considering.

Zach King


Cool video (vine) magician:

VAAMP - part 2


In this three-part series, I'll walk you through setting up a cross-platform LAMP server for local development.  I'll be using VirtualBox, Alpine Linux, Apache, MySQL, and PHP so I've nicknamed it VAAMP.


Apache, MySQL, and PHP setup



If you don't want to manually perform all the steps below, you can just download the VirtualBox appliance here.


1.  Make sure to follow Part 1 of this guide and login as root

2.  Install Apache httpd, MySQL (MariaDB), and PHP-FPM by running this command:

apk add gd mysql curl apache2-proxy php-fpm php-common php-iconv php-json php-gd php-curl php-xml php-mysql php-mysqli php-pdo php-pdo_mysql php-imap php-soap php-xmlrpc php-posix php-mcrypt php-gettext php-ldap php-ctype php-dom php-pear

3.  Configure Apache with these commands:

sed -i 's,\(LoadModule mpm_prefork_module modules/\),#\1,g' /etc/apache2/httpd.conf

sed -i 's,#\(LoadModule mpm_event_module modules/\),\1,g' /etc/apache2/httpd.conf

4.  Set httpd-mpm to default values:

cp /etc/apache2/original/extra/httpd-mpm.conf /etc/apache2/conf.d/

5.  Assuming you kept the hostname as localhost in Part 1, Step 24, configure PHP via these commands:

sed -i 's,\(DirectoryIndex index.html index.html.var\),#\1,g' /etc/apache2/httpd.conf

echo 'ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://$1' >> /etc/apache2/httpd.conf

echo 'DirectoryIndex index.html index.php' >> /etc/apache2/httpd.conf

echo '<?php phpinfo(); ?>' > /var/www/localhost/htdocs/phpinfo.php

6.  Initialize MariaDB:

/etc/init.d/mariadb setup

curl -sLo /var/www/localhost/htdocs/adminer.php

7.  Add Apache, MariaDB and PHP to the OpenRC init process (so they start at boot) and then start them:

rc-update add apache2 default && rc-update add mariadb default && rc-update add php-fpm default

/etc/init.d/apache2 restart && /etc/init.d/mariadb restart && /etc/init.d/php-fpm restart

8.  To test Apache, assuming you used in Part 1, Step 24, open a browser on your host computer and go to

9.  To test PHP, go to

10. To test MariaDB, go to and click Login

Congratulations!  You've installed a LAMP server on VirtualBox.  Head on over to the next post in this series: VirtualHost, shared folder, and DNS setup



The Man gains a point


Sadness personified into a webpage:

The perfect local development domain


Many website developers work locally on their laptops or personal computers before posting code to a centralized web server.

When running a website locally, you use (or the common alias http://localhost/ )

However, these URLs are not especially elegant or descriptive.  So, developers typically edit their hosts file to provide a more descriptive domain, like or

There are some dangers with this approach so we'll discuss the common approaches and suggest the best option:


The problem with creating your own made-up top-level-domain (TLD) is that you run the risk of that imaginary TLD becoming an actual TLD.  For example, let's say you run a company called ACME and a decade ago your IT team standardized on using *.website for all your local websites.  So, would load your public Internet site and would load your private internal company intranet site (for all machines on the network whose hosts file was configured appropriately).  This worked great...until 2014 when *.website became a generic top-level-domain (gTLD).  What if the person that reserved was a hacker or competitor?  If a new employee didn't have the hosts file configured yet (or someone was using their mobile device, etc.), they would inadvertently load a different site controlled by that external entity.  Bad news!  You're probably thinking, "Well, I'll just pick a domain suffix that no one will ever really think to register".  The reality is, with the proliferation of new gTLDs, it's just not a safe bet to create your own.


You may be thinking, "Isn't there any domain I could use for local offline sites?!"  Well, there are -- they're called reserved domains and they were built for that very purpose: example, invalid, localhost, test, and local.  None of these are particularly attractive except for the obvious choice: *.local.  Problem solved, right?  Not so fast.  Unfortunately a particular company (*cough*Apple*cough*) decided to abuse that domain for it's own purpose so they ruined it for the rest of us and it's no longer recommended for use.  Note: technically, *.test might be an acceptable alternative, but most companies already have a dedicated test environment so using *.test for a local site would be confusing.

Purchase your own dedicated-purpose domain

The safest way to ensure a particular domain suffix won't become official or be used by others is to simply buy it.  The downside to this approach is that it costs money (unless you use a free service [1, 2, 3]) and there's a slight risk of someone forgetting to renew the domain at some point and a squatter claims it, thus introducing the potential issue described in *.dev above.


This country code top-level-domain (ccTLD) was originally reserved for for East Germany but never implemented (due to the reunification of Germany).  Importantly, it was never added to the root nameservers so browsers won't recognize it as an Internet address.  Equally important, it was used internally by a couple universities so that historic precedence means *.dd won't be revoked and reassigned to a different country in the future.  It's also easy to type and nondescript -- perfect for local development.


My recommendation is to use *.local.dd because it's more descriptive and allows more flexibility -- for example, you can't whitelist *.dd in Ghostery but you can whitelist local.dd (which then whitelists all its subdomains).

VAAMP - part 1


In this three-part series, I'll walk you through setting up a cross-platform LAMP server for local development.  I'll be using VirtualBox, Alpine Linux, Apache, MySQL, and PHP so I've nicknamed it VAAMP.


Your first question is probably "Why not just use Docker, Vagrant, or XAMPP?"

Docker shows good promise, but is wildly in flux so I'll wait until OCP OCI becomes standardized.  It's also somewhat complicated to set up and use for a novice programmer simply looking to develop locally.

Vagrant does a good job of simplifying the setup and run process but customizing it requires knowledge of Ruby (which many developers may not know) and Windows support in version 1.7.2 is buggy.

XAMPP avoids additional virtualization overhead by installing Apache and PHP directly on the host OS but isn't easily scriptable to create a custom development workflow suited to your unique tastes and needs (such as installing Drush along with the LAMP stack).

Since VirtualBox is free, supports Windows, Mac, and Linux, and provides a command-line interface, it's a nice fit for my needs.  Also, Alpine Linux is smaller and more secure than many other common Linux distros so it's a good fit for basic local development.  Caveat: the Alpine Linux VirtualBox guest additions are currently in testing (at the time of this writing) so you're limited to a VirtualBox screen size of 800x600 (fortunately our use case leverages the host browser and a shared file system to communicate with the VM so this shouldn't be a problem).

VirtualBox and Alpine Linux setup



If you don't want to manually perform all the steps below, you can just download the VirtualBox appliance here.


1.  Download the latest alpine-mini1 iso file

2.  Download and install VirtualBox

3.  Open VirtualBox and choose File > Preferences...

4.  In the Network section, click on the Host-only Networks tab and then click on the + button.  This will create a new network interface

5.  Once the new network interface has been created, make sure it's selected and then click on the screwdriver button

6.  Set the IPv4 Address to and the IPv4 Network Mask to

7.  Then, click on the DHCP Server tab and uncheck the Enable Server checkbox (we'll be using a static IP instead of DHCP for this network interface)

8.  Click OK multiple times until you return to the default VirtualBox window.

9.  Click New and provide a descriptive Name and for Type choose Linux and Version choose Other Linux (64-bit)

10.  Assign the desired amount of memory to the VM

11. Create a virtual hard drive

12. Choose the VMDK format (since it's more widely used by other virtualization platforms and tools)

13. Use a dynamically allocated virtual hard drive

14. Indicate the desired disk size and then click Create

15. Once the VM has been initialized, make sure it's highlighted in the list and then click Settings

16. Click on Storage and then click on the Empty CD-ROM and use the dropdown button to choose the alpine-mini iso file from step 1 above

17. Then, click on Network and verify Adapter 1 is set to NAT

18. Click on the Adapter 2 tab and click the checkbox to enable it and choose Host-only Adapter and choose the new network interface you created in step 5

19. Click OK multiple times until you return to the default VirtualBox window.

20. Click Start

21. Login as root

22. Then run setup-alpine

23. You'll be prompted to select your keyboard

24. Choose a hostname (or just press ENTER to keep the default localhost).  For eth0 (NAT) press ENTER to keep the default dhcp.  For eth1 (host-only) type and press ENTER.  Then, press ENTER for the remaining network options to keep the defaults.  Note: in the remainder of this guide, if I don't provide a recommendation, you can just use ENTER to keep the default Alpine Linux recommendation.

25.  Choose a mirror (I chose 1 since the default scan 'f' seemed to hang)

26. When prompted to choose a hard disk, select sda and then sys and finally type y to install Alpine Linux to the virtual hard disk you created in step 14.

27. After the installation is complete, type poweroff to shut down the VM

28. Click on Settings

29. Click on Storage and then click on alpine-mini to highlight it.  Click on the CD-ROM dropdown and choose Remove disk from virtual drive and click OK

30. The CD-ROM drive should now show as Empty

31. Click OK multiple times until you return to the default VirtualBox window.

32. Click Start

33. When the VM boots, login as root with the new password you were prompted to set during the alpine-setup phase.

34. You should be able to access the Internet (thanks to the eth0 NAT network interface)

35. You should also be able to ping the Alpine Linux guest VM from your host computer (thanks to the eth1 host-only network interface)

Congratulations!  You've installed Alpine Linux on VirtualBox.  Check out the next post in this series: Apache, MySQL, and PHP setup