Quick and Dirty PHP 7.0 set up on Ubuntu 14.04 with APCu

This is how I got PHP 7 and APCu running on one of the entry-level Digital Ocean droplets:

PHP 7

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:ondrej/php-7.0
apt-get update && apt-get purge php5-fpm && apt-get --purge autoremove && apt-get install php7.0-fpm php7.0-mysql php7.0-gd php7.0-dev

If you need additional php7.0 packages, check the list:

sudo apt-cache search php7

In my enabled nginx site configs (I'm sure there's a place to put this globally, but I only had a couple of sites, so I didn't bother researching that for now):

Replace:

fastcgi_pass unix:/var/run/php5-fpm.sock; 

With:

fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;

APCu

git clone https://github.com/krakjoe/apcu

Follow the instructions for building APCu in the INSTALL file

In addition to the updates to php.ini described in the INSTALL file, update the 'extensions_dir' directive:

extension_dir = "/usr/lib/php/20151012/"

Do the same for both the FPM and CLI versions of php.ini

Restart PHP-FPM and Nginx:

sudo service php7.0-fpm restart
sudo service nginx restart

That did it for me. With APCu installed, I can continue to use APC as the driver for session and cache in my Laravel 5 apps when Memcache, Redis, etc. are overkill.

 

Using the Laravel Homestead "serve" command with Oh-My-Zsh

So I run an  "extras" script  after installing Laravel's Homestead that installs LDAP, Oracle Drivers, and Oh-My-Zsh among other things. But afterwards, I cannot run the "serve" command in the homestead VM to add new Nginx sites. I've finally figured out that the serve command is actually a bash shell alias function thingy inside .bash_aliases, so it's being ignored once I switch to Oh-My-Zsh.

Simply copying the serve function to .zshrc doesn't work due to some apparent syntax differences with bash and zsh. After digging around a bit, I've slightly modified the function to work now with zsh inside .zshrc:

Hopefully this helps someone else, or maybe someone has a better solution altogether.

Using Laravel's Artisan with Git for Deployment.

There are many ways to handle web application deployment. Decisions on what method to use depends a lot on what type of hosting environment you are using, as well as the size, scope, and critical nature of the application. 

I handle the deployment of several applications with my own artisan "push" command that utilizes Laravel's SSH remote facade. The command is below, but first there's a little setup necessary:

Pardon the Mess

I just pushed up a ton of changes to the "Brewski" platform (maybe "platform" is a bit much), so I'm dealing with a few errors, but the big thing is that I decided to ditch the markdown editor I was using and switched to ckeditor. There's just so much more I can do with it and it's easier for a non-tech person to use. The downside is most of the posts are currently a little f-ed up while I fix some formatting problems.

Running Gulp.js in the background (OS X)

I discovered (or really just stopped ignoring references to) Gulp.js today and decided to give it a go. Now, this is not a post about what Gulp.js is - I'm assuming if you are reading this, you already know. This is about how to make me actually use it. The problem I ran into with Gulp right away was when you run it in a project in the terminal (`gulp`) with a gulpscript.js that watches certain folders (css,js, etc.), it has to just keep running in a terminal window in order to keep "watching" these folders. Even if you run the command with NOHUP to allow it to run in the background and free up the terminal session, you still have to remember to start it up for each project you're working on.

Controlling Laravel Homestead VM From Any Folder in Terminal

Having a single Vagrant VM for all of my projects is nice, but I was used to controlling Vagrant from within a project's folder in Terminal and not having to go back to the central Homestead folder to run things like vagrant up or vagrant reload.

Adding these to my Oh-My-Zsh config (.zshrc) seems to do the trick:

alias devup="cd '/Users/gtaylor/Sites/Work/Homestead' && vagrant up && cd - 1> /dev/null"
alias devreload="cd '/Users/gtaylor/Sites/Work/Homestead' && vagrant reload && cd - 1> /dev/null"
alias devdown="cd '/Users/gtaylor/Sites/Work/Homestead' && vagrant halt && cd - 1> /dev/null"

I'm using these in conjunction with `alias dev='ssh vagrant@127.0.0.1 -p 2222'` from the Homestead documentation.

"Extending" Laravel's Homestead

I put off moving my existing vagrant dev VMs over to [Laravel's Homestead](http://laravel.com/docs/homestead) for a couple of reasons:

  1. It doesn't completely match my production environments (Ubuntu 14.04 instead 12.04, PHP 5.5 instead of 5.4, Nginx instead of Apache).
  2. I knew I'd need to customize the VM anyway and I already had that worked out with my existing VMs (note the plural).

Thoughts on Laracon Day 1

I'm at Laracon 2014 in NYC, and as I predicted, it's a little overwhelming - in Lower Manhattan, seeing in-person all of these people I've been following and learning from the last year or so, and listening to really smart people talk about stuff which, in some cases, is a little over my head. But it's all good, in spite of a few kinks with the venue.

 

I think I fully grasped/comprehended about 50% of the talks, which is fine. That's probably a better percentage than some design patterns books I've read the first time thru. Taylor Otwell's keynote was an exception in that I fully understand the headaches with dev environments and deployment, so Homestead and Forge providing the "artisan"-like bookends to developing with Laravel makes perfect sense. I hope that Forge can (eventually) work with existing VPS environments to some degree, as I don't deploy new environments often, but would love to use it for some existing VMs that don't use the hosting providers currently supported.

 

Photo Credit: https://twitter.com/brianwebb01/status/467072660023676928