Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Laravel News:
Laravel Bash Aliases
Aug 24, 2017 @ 15:45:29

For the Laravel users out there the Laravel News site has shared some handy Bash aliases you can use from the command line to improve and streamline your workflow.

Bash aliases are shortcuts added to a file that allows you to reference another command through more memorable words, abbreviations, or characters. For example, if you use Git you may run git status many times throughout the day, so to save yourself time and keystrokes you could alias gs to git status and it’ll automatically expand and call the proper command.

Over the years I’ve seen a lot of unusual aliases and many are unique to the person. Shortcuts that make sense to me, might be confusing and weird to you. That’s what makes these so fun.

He shares how to create a basic alias in your .bash_aliases file and then shares some from different users in the community:

  • WaveHack
  • Jeffrey Way
  • Bill Mitchell
  • freekmurze
  • sebastiaanluca

Each contribution includes the code needed to define their preferred aliases. They cover everything from general console command simplification out to more complex Laravel-specific functionality.

tagged: laravel bash alias community contribution tutorial

Link: https://laravel-news.com/bash-aliases

Rob Allen:
Autocomplete Composer script names on the command line
May 15, 2017 @ 09:43:22

Rob Allen has a quick new post with a handy script you can use to auto-complete Composer script names on the command line (for bash).

As I add more and more of my own script targets to my composer.json files, I find that it would be helpful to have tab autocomplete in bash. I asked on Twitter and didn't get an immediate solution and as I had already done something similar for Phing, I rolled up my sleeves and wrote my own.

He created the bash completion file where Bash could locate it (a special "bash_completion.d" directory). He includes the code you'll need to have in the bash script and briefly explains how each line works. He also includes an example of the output showing how the script catches both the built-in and custom commands as auto-complete options.

tagged: autocomplete composer script bash commandline tutorial

Link: https://akrabat.com/autocomplete-composer-script-names-on-the-command-line/

ServerGrove Blog:
Linters for PHP projects
Jun 03, 2015 @ 12:34:53

In a new post to the ServerGrove blog they look at linting tools for various circumstances including standard PHP, Twig templates and Composer configuration.

Today’s projects are built up from dozens of different components, configuration files, third-party libraries, tests, build scripts, etc. And even if you have the greatest test suite, bad things can happen sometimes. It’s important to catch bugs as early as possible, and syntax validators can be a great (and easy) addition to your continuous integration system. You would be surprised at how many problems are caused by syntax errors. At ServerGrove, we see these kind of problems with our clients almost every day.

Their list shows you how to lint (syntax check) several different types of content:

  • standard PHP code
  • Twig templates
  • Composer configuration
  • XML files
  • Bash scripts
  • JSON files
  • YAML files

Some of them use tools that already come built-in (like PHP's "-l" or Twig's "twig:lint") but others require the use of external software such as xmllint or melody. Command examples are also included for each.

tagged: lint project types twig bash composer xml json yaml tools

Link: http://blog.servergrove.com/2015/06/02/linters-php-projects/

Joshua Thijssen:
Realtime PHPUnit
Feb 05, 2014 @ 09:22:52

Joshua Thijssen has a new post to his site sharing an interesting tool for those using PHPUnit for testing. It's a real-time plugin that executes your tests as soon as something in your files change.

Not all IDEs (actually, i haven’t seen even one IDE that does this), can run your unit-tests as soon as something changes. Inspired by Greg Young’s Mighty Moose system, the following script runs inside a shell, will wait for changes in your PHP-files, and runs the corresponding unit-test as soon as something changes. It doesn’t run the WHOLE unit-tests suite, but merely the test that matches up the source file.

His tool, found here on Github and uses a simple bash script that uses the file name being saved to locate the matching test and execute it, reporting back any errors that might have popped up. This could easily be hooked into most IDEs out there and keep the developer in one place.

tagged: realtime phpunit bash script

Link: https://www.adayinthelifeof.nl/2014/02/02/realtime-phpunit/

Kevin van Zonneveld:
It's Almost 2014 and We Are Still Committing Broken Code
Dec 30, 2013 @ 09:19:28

Kevin van Zonneveld has a new post that, while not PHP specific, does have a handy script that will help you stop committing broken code.

Whatever the reason, it's almost 2014 and we are still committing broken code. This needs to stop because best case: Travis or Jenkins prevent those errors from hitting production and it's frustrating to go back and revert/redo that stuff. A waste of your time and state of mind, you were already working on other things. Worst case: your error goes unnoticed and hits production.

To help resolve the problem, he suggests using the "hook" system common to most version control software. In his specific example, he shows the use of a pre-commit hook that fires off a bash script on the files being committed. He includes the full code for this bash script that includes a check for PHP scripts using the built in PHP linter (the "-l" option on the command line). He also includes the commands and updates you'll need to make to get it installed on git.

tagged: git precommit hook syntax error bash script tutorial

Link: http://kvz.io/blog/2013/12/29/one-git-commit-hook-to-rule-them-all/

Michael Maclean:
Why one-line installers are a bad idea
Sep 21, 2012 @ 11:35:29

There's a feature that's usage has been showing up more and more in software projects (both open source and not) that allows you to install their system with a single line command, usually involving curl and maybe piping it to a shell. In this recent post Michael Maclean takes a look at this trend and some of the possible pitfalls of the approach.

There has been a trend in the last while for various bits of useful software to have a one-line shell command recommended as the installation method. The usual form of this is to pipe something like curl or wget to some interpreter, be it bash, php, ruby, or some such. [...] This [type of] command takes the output of curl and pipes it straight to bash. I have several issues with this.

His three main points center around the fact that you cannot inspect the code before executing it with this method, that you can't verify the source of the code and that it teaches users bad habits of trusting in "magic commands" like these.

tagged: installer oneline opinion curl bash shell magic

Link:

Zumba Engineering Blog:
Creating bash completion to your console application
Aug 21, 2012 @ 09:47:52

On the Zumba Engineering blog there's a new post showing you how to implement bash shell "autocomplete" with a special option for a second argument.

This weekend I saw the bash completion for CakePHP from Andy Dawson and had an idea to do the same for our service application, because we frequently forget the exactly job class or method name and add extra steps to verify these names before execute the job. I read his code, made some research and finally get our bash completion working fine.

In his case he wanted to see what things a module in the application had to offer, so he implemented a "__check__" argument that looked at the third argument and used reflection to get the methods allowed for it. Also included in the post is the bash alias you'll need to set up to get it working (and where to put it to make it cooperate).

tagged: bash autocomplete console tutorial reflection

Link:

Andrew Johnstone's Blog:
Vagrant, Automating PHP/MySQL Installation with bash/slack
Dec 12, 2011 @ 08:58:08

Andrew Johnstone has a new post to his blog with a look at using Vagrant for continuous deployment of a PHP-based application.

Vagrant is simply a wrapper around Virtualbox headless that allows for provisioning virtual machines with support for puppet, chef-solo, chef, and bash. This allows you to automate the deployment and sandboxing of development sites. Additional base box images can be found at vagrantbox.es.

He walks you through the full process of setting up a first deployment - getting Vagrant installed, updating the config for a squeeze64.box image, configuring a virtualhost on the Apache web server and setting up a "preinstall" script to configure things like MySQL and install a long list of packages (via apt-get).

tagged: continuous deployment vagrant mysql slack bash

Link:

Derick Rethans' Blog:
Multiple PHP versions set-up
Nov 07, 2011 @ 09:14:00

Derick Rethans has a new post today looking at a method for setting up multiple PHP versions on the same machine and switch between them with a little help from some simple bash scripts.

For many of my projects (both hobby and commercial) I need to support many different PHP configurations. Not only just different PHP versions, but also debug builds, ZTS builds and 32-bit builds. In order to be able to test and build extensions against all those different PHP configurations I have adopted a simple method that I'm sharing with you here.

Using this script he can tell his system to pull the latest version of any release from SVN and try to compile it. The trick is putting each of them into a different directory under /usr/local. He uses another small shell function (with a function called "pe()") that sets up the pathing to the right release, complete with its own locations for PEAR/PECL and a php.ini.

tagged: multiple version setup bash script switch tutorial

Link:

Matthew Weier O'Phinney's Blog:
Converting DocBook4 to DocBook5
Jul 20, 2011 @ 09:55:50

In this new post to his blog Matthew Weier O'Phinney looks at the steps he took to convert over the documentation for the Zend Framework 2 from the DocBook 4 formatting over to DocBook 5. Included in the post is some of the (PHP and bash) code he used to make the switch.

Within the Zend Framework 2 repository, I recently performed a conversion from DocBook 4 to 5. [...] Interestingly, for DocBook5 being available in beta since 2005 and an official standard since 2009, there is very little material on migrating from DocBook 4 to 5.

Right from the start he came across a few problems with the included conversion process that're a part of the "db4-update.xsl" definitions. He has a list of eight steps he had to perform on the current DocBook 4 formatted documentation to make the conversion work smoothly including:

  • Identify files containing entity declarations, and skip them.
  • Run the XML file through the db4-upgrade.xsl stylesheet and restore XML entities from the previously placed markers
  • Fix programlisting elements (replaces entities with original text and wraps in CDATA).

He details these steps in a few different sections talking about handling the entities, creating some helper scripts and how to put the two code parts together in a single bash script that can be run on the entire documentation set. If you're just looking for the code, you can find it on his github account.

tagged: convert docbook4 docbook5 xsl entities xml bash

Link: