Matt Stauffer has posted the latest article in his "New Features in Laravel 5.3" series today. In this new tutorial Matt focuses on the creation of console commands - additional functionality you can add in to the pre-existing "artisan" command handling.

Before Laravel 5.3, defining an Artisan console command—something like php artisan sync:dates—required you to create a new class for that command and register it in the Console Kernel. This is fine, but sometimes it feels like overkill for what might end up just being a single line of functional code.

As of Laravel 5.3, you'll notice that there's a new method in the Console/Kernel.php file named commands(), and it loads a new file at routes/console.php. This new "console routes" file allows us to define Artisan console commands with a single Closure instead the prior "define a class then register it in the console Kernel" flow. Much faster, much easier.

In v5.3 you define commands using "routes" along with a simple description using fluent statements. He shows how to add a simple command, one with input and a more streamlined example pulling values directly from the "route" signature.

The TutsPlus.com site has updated their "Building Your Startup" series with their latest tutorial showing you how to build advanced scheduling commands allowing for things like repeating meetings, updating the meeting details and rescheduling.

I also began to realize that the ability to adjust meetings easily after they've been scheduled could make or break the Meeting Planner brand. [...] In today's tutorial, I'll cover expanding the navigation bar using Bootstrap and the basics of building some of the advanced scheduling features within Meeting Planner. Next week, I'll review building the more complex feature for participants to request change(s) and for others to accept or decline them.

He starts with the frontend, updating the navigation bar to include links to other functionality for meeting changes, repeating and showing planning activities for the meeting. He uses Bootstrap's single-button dropdowns for this and includes the code to add them to the UI with a bit of code in the view. He then gets into the main functionality of these changes showing the code to:

• make changes to a current meeting
• reschedule a meeting
• repeat a meeting
• resend invitations

The next part in the series will take a look into social engineering and UX needs for the application along with some other smaller changes.

The Master Zend Framework site has posted a tutorial that seeks to help you get the most out of Composer on the command line with some essential tips beyond just he basics.

I know that a series on Composer might seem odd. But, as Composer’s been a part of PHP for so long now, I feel that it’s something which most of us take for granted. It’s revolutionised the PHP landscape, making it easier than ever before to build great software in PHP. But do we really know how to get the most out of it. For that reason, I’ve created this series, so that you level up your skills and really get the most from it.

In part one of this series, I’m going to take you through Composer’s command-line. I’ve cherry-picked a key subset of the command-line options, and focused in on key switches, so that you can do more than you already can.

He skips over the basic "require", "install" and "update" handling covered in many other tutorials and instead covers:

• project creation
• the "show" command to list installed packages
• "remove" to drop a package from the current dependencies
• using "depends" to see package dependencies
• finding outdates packages with (appropriately) the "outdated" command
• seeing suggested packages with "suggest"

For each item on the list there's an example of the command, what kind of options is allows and, for some, the output generated as a result.

On the Yappa blog there's a new post about their "trip" towards a PHP and Docker based development environment and the steps they took along the way. The post even includes the full commands and configuration changes you'll need to replicate it.

During a regular work day we work on several PHP projects. Sometimes new projects, but also legacy code which still require earlier versions of PHP. We all work on Macbooks and want to switch quickly and easily between projects. The project requirements vary, the PHP version may be different, or additional services may be required (such as Redis, Elasticsearch, ..).

Unable to mimic the production environment without spending countless hours installing packages on a virtual box for each project.

They start with some of the initial steps they tried including a single local development server and remote servers but points out the issues with each. Ultimately they decided to give Docker a try and came up with their ("almost perfect") development environment. From there they get into the steps to reproduce, the more technical parts, and list the requirements you'll need and the steps in the setup process.

In this post to his site Emanuele Minotto looks at commands in Composer. This functionality lets you execute "commands" with Composer command line options. These are not the same as the "scripts" functionality that allows you to specify shell commands to execute when certain events are fired.

Recently I’m considering a not-so-common Composer feature: commands (scripts). Composer already provides some hooks, you can find the list of provided hooks here: getcomposer.org/doc/articles/scripts.md#event-names

These hooks you see aren’t the same commands I mean in this article, because can’t be invoked using "composer post-install-cmd", I’m going to list some scripts I found useful, but before let me explain some reasons why I think they should be included in your composer.json.

He starts by answering a few of the common questions about this command handling including how it should be done can be tested. He then covers three commands you can use to help with testing these commands:

• composer test
• composer compile
• composer check-style

For each he provides an example of the configuration in the "scripts" section of the composer.json file when each of these special command line options are used.

Matt Stauffer has posted the latest in his "What's New in Laravel 5" series today with a look at the changes in creating Artisan commands with a newer, simpler syntax.

If you're not familiar with Artisan commands, they're command-line functions that you can run to interact with your Laravel application. If you run php artisan from the command line in any Laravel application directory, you'll see a list of all of the Artisan commands available for each app. As you can see, Laravel comes with quite a few enabled out of the box.

He starts with a look at the old way of creating the commands using the "artisan make:console" command to build the class and an example of its contents. This version requires a good bit of extra code to reference things like arguments and define required parameters. He then compares this with the new way with a much simpler syntax and reduced about of code overall. One of the main differences he mentions is the concept of a "signature" for the command - a specially formatted string that defines configuration such as required and optional parameters. He finishes the post with a few examples of these signatures.

Mike Bronner has a new post on Medium.com about installing PHPCI on a Laravel Homestead instance and have it able to execute your builds.

PHPCI is a nifty little swiss-army-knife for your development toolbox. [...] It will monitor your source repositories for changes, and trigger a new build when it sees activity. Then it will let you know if anything went wrong or can be improved. This comes in handy to improve your code quality and minimize errors and issues down the road. In the following section we’ll go through the process of installing PHPCI in Homestead.

He goes through the full process of getting the necessary software installed and all of the commands you'll need to:

• Adding the PHPCI database
• Clone the PHPCI code
• Configure the PHPCI install
• Set up the cron to run automatic builds
• Configure MySQL
• Set up the Homestead instance for the new PHPCI site

Check out the full post for more details.

Matthias Noback is back with another post in a series looking at using a command bus to execute more complex code in somewhat of an isolation from the rest of the application. In this new post he moves on to some of the secondary tasks that happen inside the commands and how those relate to event handling.

In the previous posts we looked at commands and the command bus. Commands are simple objects which express a user's intention to change something. Internally, the command object is handed over to the command bus, which performs the change that has been requested. While it eventually delegates this task to a dedicated command handler, it also takes care of several other things, like wrapping the command execution in a database transaction and protecting the original order of commands.

He gets into some of these secondary tasks inside of the commands themselves - smaller actions that need to be done as a part of the execution of the command as a whole. He points out that it's tempting to do everything inside the command, but that it can lead to maintenance issues down the line. He suggests that the command shouldn't perform these tasks at all. They should be handled by an event system that uses event objects to pass off responsibility for performing actions to other objects (for example, handling the post-signup process once a user is created). He's done some research on some event dispatchers currently available but found them lacking in one way or another. Instead he opted to integrate one into his SimpleBus library (EventBus) to provide an integrated way of handling these secondary events. An example of it in use is also included.

The SitePoint PHP blog has a new post from Matthew Setter today sharing a Composer cheatsheet he recently discovered with an example of the common commands and "composer.json" file structure.

Unless you’ve been living under a rock, today’s PHP isn’t your grandmother’s PHP; it’s an entirely different, much more elegant and mature language with countless improvements and additions. One of the key additions is Composer, the de facto standard for managing PHP project dependencies which, by default, gives you access to hundreds of ready-made libraries, via Packagist.org.

He goes through the parts of the guide, introducing some of the commands and covering the details of the full "composer.json" JSON structure. There's also a video introduction if you'd like the more visual version.

Tobias Schlitt has picked by up his "comfortable PHP editing in VIM" series today with this lengthy post with loads of helpful VIM tips to share with PHP developers everywhere.

More than a half year after my last "Comfortable PHP editing with VIM" post, I take up this series again, although I decided to let it die in January. Sadly I did not find any time by now, to extend PDV (the PHP Documentor for VIM plugin) further than it's version 1.0.1, which is available through vim.org and on my SVN. Anyway, I collected a lot of (at least for me) helpful VIM tips, which I'd like to share here

The post contains tons of tips on subjects such as:

• Find matching brace
• Indenting and unindeting
• Emergency help
• Macros

and many more. For each subject, there's an explaination of a situation you might need it in and, of course, the tip itself. He also links to the earlier parts of the series (one through four) for those wanting to catch up.