Stephen’s Octo Blog

I like to Tinker

Switch Between PHP and HHVM in Terminal

This is something I’m trying to remember, and it’s something that’s been answered before here.

I’ve beginning to experiment with HHVM as an alternative to using PHP, so I figured this would be useful to try out. Switching out the language that’s called when using PHP on the terminal is as simple as using this command:

sudo /usr/bin/update-alternatives --install /usr/bin/php php /usr/bin/hhvm 60

This will do it without any input, and you should be able to check by running. php -v. If you get hhvm version stuff, you should be good.

My next important question was how to switch back to using PHP. Again, simple:

sudo /usr/bin/update-alternatives --config php

It will then ask you to select from a list of options. My options were:

1
2
3
4
5
6
7
8
9
There are 2 choices for the alternative php (providing /usr/bin/php).

  Selection    Path            Priority   Status
------------------------------------------------------------
  0            /usr/bin/hhvm    60        auto mode
  1            /usr/bin/hhvm    60        manual mode
* 2            /usr/bin/php5    50        manual mode

Press enter to keep the current choice[*], or type selection number:

Migration From Dreamhost to Namecheap and Github

I recently decided that I no longer needed to use DreamHost for hosting my website now that I’ve been using Octopress.

The initial setup for this appears to be quite straightforward, but it is advised that you follow the exact directions otherwise you will have issues. I had some initially, and I ended up having to destroy my repository and start over again.

Instructions can be found here

Side effects:

It appears my ability to use rake preview is broken, but that might really be related to my VM not appearing to forward the 4000 port, which I can’t tell if that’s an issue with the machine or not. I may just replace the VM.

I also noticed that this process doesn’t really seem to enjoy posting from more than one computer. I found out the hard way and I ended up having to blast the repository completely and start from scratch. I found that once you run rake setup_github_pages and tried to generate and deploy the site it would say something along the lines of being out of sync.

Solution:

After running rake setup_github_pages, don’t run generate or deploy, but instead go into the new _deploy folder and run git pull origin master. It should merge your current master branch into the folder. There will be an index merge conflict, which is easy to delete the old one. Doing this should allow you to run rake deploy successfully to commit the blog.

If you don’t plan on maintaining this blog with more than one computer, then this probably isn’t the biggest problem for you.

Use Varnish With Nginx and Ubuntu

Feels like I haven’t updated this blog in a while, so I’ll add a tutorial that I learned about a bit ago when trying to address speeds with Drupal.

For starters this was done on an Ubuntu VM. From this website, follow the tutorial to install Varnish:

1
2
3
4
5
apt-get install apt-transport-https
curl https://repo.varnish-cache.org/ubuntu/GPG-key.txt | apt-key add -
echo "deb https://repo.varnish-cache.org/ubuntu/ precise varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.list
apt-get update
apt-get install varnish

Edit this file: /etc/default/varnish, under ALternative 2, configure the beginning port :6082 to be :80 like below:

1
2
3
4
5
DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

Next edit the file located at /etc/varnish/default.vcl. Change to port to from 80 to 8080 like below:

1
2
3
4
5
6
7
8
backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .connect_timeout = 60s;
    .first_byte_timeout = 60s;
    .between_bytes_timeout = 60s;
    .max_connections = 800;
}

Now the next step would be to edit the port used by nginx. Each server(it you have it configured that way) would need to be switched from 80 to 8080. The location of my config files are /etc/nginx/sites-available.

Notes:

If you’re using this on a vagrant and have ports forwarded, for example I use homestead for laravel, you will need to change the forwarded port from 8000 to 8080, otherwise it won’t work properly, and nginx will likely not show your sites.

Finished, now test:

To test, you can run varnishstat, and that should give you data live as you access the domain affected by varnish.

Notifications Using Gulp-Notify on Vagrant With Terminal-Notifier

I’ve been looking using grunt/gulp for automation of my different tasks, such as css/js minification, and image manipulations so when I found out about automating tests for phpunit, I decided to give a try.

Note: I haven’t really seen anything relating to this other than this, but I couldn’t quite get it to work using his bash script, so I ended up a making a few adjustments to his.

I develop using a Vagrant VM, so while installing most of this stuff on the host machine will work fine, I want it to be mostly kept to the VM. The tests are also running against the VM’s databases, not the local machine, so it makes more sense to keep dev separate from the Host Mac OSX.

[1] Install terminal-notifier

I used homebrew, so I just ran update and installed terminal-notifier:

1
brew update && brew install terminal-notifier

This added terminal-notifier to my applications folder, it also linked the app to my $PATH, which allows me to call it from the terminal.

[2] Install Vagrant-Notify

I will be using terminal-notifier for this, since it’s the stock notification app for Mac. This piece was a bit weird when initially installing. It worked best for me when I installed the plugin with the Vagrant vm off, it will give me an error about ruby running if the machine was already running. Killing the rogue ruby task with activity monitor would fix this as well.

From inside the folder with your Vagrant:

1
vagrant plugin install vagrant-notify

This piece will require another file called notify-send, preferably saved in usr\local\bin

1
terminal-notifier -appIcon "$2" -title "$4" -message "$5"

Make sure this file has no extension and is executable. sudo chmod +x /usr/local/bin/notify-send

This is the part where I couldn’t quite get it to work like in the tutorial I included, so I ended up moving around the numbers that were being submitted to the script from gulp. These are the numbers that worked for me, YMMV. I believe the gulp-notify sends more by default now.

[3] Install Gulp, and dependencies

Used NPM for this on my Vagrant VM, since this is where gulp will be called:

1
2
3
npm install gulp --save-dev
npm install gulp-notify --save-dev
npm install gulp-phpunit --save-dev

[4] Create Gulp File

I gathered this from a couple of different gulp.js files.

Note: Can be edited from host or guest machine, since in my case the gulp file will be at the base of my project folder.

[5] Check that it works

You can run gulp, or you can use gulp test

Which should return a notification of some sort. This will likely not be the best way to address phpunit tests, especially since currently there are only 3 tests. That’s not a lot, but if the project was much bigger, say 30-40 tests, I can see this being a dumb idea. I’ll likely not use this for larger projects, or at least implement a count that only runs the tests every so often.

Troubleshooting

The difficult part about this was getting the script to return the proper notifications. It initially wouldn’t give the message, and instead was using the default img that is included with the script. I ended up moving the numbers around and that seemed to address the issue.

Force Regeneration on Jekyll Watch

I noticed that after migrating dev work to my new Vagrant vm, jekyll doesn’t seem to want to regenerate posts whenever I make a change and try to preview it. The simple change I found from a stackoverflow post is instead of calling just jeykll build –watch, use jekyll build –watch –force_polling.

I replace the this line in the rakefile:

1
jekyllPid = Process.spawn({"OCTOPRESS_ENV"=>"preview"}, "jekyll build --watch")

with:

1
jekyllPid = Process.spawn({"OCTOPRESS_ENV"=>"preview"}, "jekyll build --watch --force_polling")

Both generate rake watch and rake preview use this line, so make sure to replace both. This seems to have solved my issue with rake preview/watch. The question also has an answer suggesting that vagrant uses a special driver for the file syncing between guest and host machines, making the regeneration not work properly, so that’s something to keep in mind.

Fetching Upstream Changes

I found this very useful in merging changes for Octopress, granted I ended up having to wipe the entire project out anyways.

git remote add upstream https://github.com/imathis/octopress.git

This way I’m able to fetch anything that happens to the master of octopress by simply running

git fetch upstream

If I want to go ahead and merge:

git merge upstream/master

I can’t tell if there’s a difference between using https:// or git://, so I’m sticking to what github uses as an example.

Start Nginx at Launch on Mavericks Mac OS

Update 1/5/15:

Fixed a typo, it should be “sudo cp /usr/local/opt/nginx/*.plist /Library/LaunchDaemons“ not “sudo cp /usr/local/opt/nginx/*.plist /Libary/LaunchDaemons“

Also added chown for file, in case it doesn’t have proper permissions.

For the longest time I couldn’t get the piece to work, but I finally figured it out using launchctl as a somewhat basis for troubleshooting. I used homebrew to install nginx which is easier and works for the most part. First the instructions on how to install nginx using homebrew:

brew update && brew install nginx

Next what you want to do is have launchctl start nginx automatically for you. You can do this in several ways, but I’ll cover two:

Option 1 - Symbolic link

For this option you will symbolic link the .plist file included with nginx to have launchctl launch nginx using the proper permissions. Then use launchctl to list the resulting loaded file.

The link you’ll need to use is something along these lines:

sudo ln -sfv /usr/local/opt/nginx/*.plist /Library/LaunchDaemons

Homebrew places a symbolic link of the nginx folder inside opt making it easier for symbolic links, at least in my opinion anyways. The reasoning to remember for this is:

Option 2 - Just copy it to the folder

sudo cp /usr/local/opt/nginx/*.plist /Library/LaunchDaemons

Bonus - Ensure proper file permissions:

sudo chown root:wheel /Library/LaunchDaemons/homebrew.mxcl.nginx.plist - Credit to Burak

The reasoning behind this:

  1. /Library is the system Library folder, rather than the user ~/Library folder. It’s used because it needs system access, and it’s easier for all users to access it.
  2. Sudo is used because nginx needs root permissions. Especially if you opt to change the default port from 8080 to 80.

Next what you want to do is have launchctl load the file for you automatically:

sudo launchctl load -w /Library/LaunchDaemons/homebrew.mxcl.nginx.plist

  1. You need sudo for this since it’s in the system Library.
  2. You need to use the -w option, otherwise it won’t load.

To troubleshoot the file loading use this:

sudo launchctl list | grep 'homebrew'

You should get a list that shows homebrew.mxcl.nginx

If all else fails:

Option 3 - Just load it when you need it

If you don’t care about automatic use the normal commands for it:

sudo nginx -s stop - Stop Nginx sudo nginx - Start Nginx sudo nginx -s reload - Reload Nginx

This actually took me a bit to figure out, so I decided to make a post for future reference.

Homebrew and PHP 5.5.11 Snag

Upgrading Notes

I updated from 5.5.8 to 5.5.11 today. After the upgrade, I noticed that anything using fpm/php had stopped working with nginx, I was getting a Bad Gateway Error. Checking my console I noticed fpm had spewed out a few errors since the update time, indicating that it wasn’t working. I tried running php-fpm from the command line, and it started right up with no problems, all my php sites worked after that. This gave me the impression that something with my plist file, the file for starting php automatically, wasn’t working correctly. That’s when I decided to make a note of this in an article.

In other words:

If you are upgrading from 5.5.8 to 5.5.11 using the command brew upgrade be aware that the .plist file used in .11 might be spelled differently than what’s in .8. This, depending on how your environment is setup could break your php-fpm, and possibly php. Make sure to swap out the file names by running these commands first:

1
2
launchctl unload ~/Library/LaunchAgents/homebrew-php.josegonzalez.php55.plist && rm ~/Library/LaunchAgents/homebrew-php.josegonzalez.php55.plist
ln -sfv /usr/local/opt/php55/*.plist ~/Library/LaunchAgents && launchctl load homebrew.mxcl.php55.plist

Additional Notes:

  • This affects you if you symlink the .plist files to ~/Library/LaunchAgents, or if you cp them as well, since the file is a different name.

  • My plist prior to 5.5.11 was always a variant of this: homebrew-php.josegonzalez.php5x.plist. After the upgrade it’s now named homebrew.mxcl.php55.plist.

Fords on Fourth Car Show

I went to a local car show called Fords on Fourth yesterday. Here are some of the photos I took. Lots of mustangs really, but here’s some of them. More of them are located here in my Tucson Album: Album: Tucson

Gist Test

I wanted to try posting gists as a test. It seems to work fairly well, but for some reason I was having problems with it not finding it resulting in a 301 error.

Here’s a codeblock example:

Meh - hello.rb
1
puts "Hi!" unless sad