On the Laravel News site there's a new post sharing a workflow developed by Bill Clark that makes searching the PHP documentation with the Alfred tool easier.

PHP Docs workflow for Alfred by Bill Clark is a workflow for searching the PHP documentation from Alfred directly. The PHP Docs workflow code builds on Till Krüss’ Laravel Docs Workflow for Alfred that we recently covered.

[...] You can search the PHP documentation by opening up Alfred and prefixing your search with “php” and then the search term.

They give an example of how to search the documentation and a screenshot of the resulting list. You can find out more and get this Alfred workflow for yourself over on the GitHub repository for the project.

In a post to his site Keith Mifsud shares his recommendations around a good workflow for developing PHP applications. Composer and GitHub play a part in the process as does the use of Git and your IDE of choice.

Continuing from the previous post Developing a Command Bus in PHP, we will look into how to get started in setting up our composer library project. Although my PHP software development workflow does vary slightly from project to project, most steps are more or less the same. Whether your project is the result of a successful proposal or you want to build an open source composer package like we’re doing here, this post will guide you in working with PHP the right way. If you are learning PHP from scratch and find that I am missing some intermediary steps or making assumptions, please feel welcome to comment below and I’ll be more than happy to explain in more detail.

He then walks through the steps in the process, each with explanation (and screenshots where appropriate):

• Getting organized and planning the application features
• Creating the GitHub repository and setting up the Kanban board
• Defining a release milestone
• Setting up a local Homestead instance for development
• Setting up Git and your IDE

The final step is to create the composer.json configuration file that defines the basic information about the project, any dependencies and the autoloading paths.

On the SitePoint PHP blog author Younes Rafie has returned with another tutorial, this time with a focus on how Postman can help master your API workflow by making use of several of the features it already includes.

Building good APIs is hard, and anyone who had the chance to do so can relate to this. A project can easily grow to become a mess. One can keep trying to adopt an approach to make it more enjoyable, like trying a documentation-first workflow, but something always feels clumsy.

I was trying out Postman lately, a tool we’ve briefly covered before, and I discovered that they’re doing a great job by providing an integrated environment for different components of an API, like authorization, testing, documentation, versioning, etc.

He then goes through the use of the tool, including screenshots along the way for:

• Making requests
• Authorization
• Environment Variables
• Testing
• Validating JSON schemas
• Working with collections

The post finishes up with a look at generating documentation for the API using Postman's "View in Web" feature including integrating example calls and publishing it. There's also a look at exporting and importing data and a few links to some other helpful resources.

On the SitePoint PHP blog there's a new post from author Shahroze Nawaz that shares the results of a survey performed with several "prominent PHP community members" about their usual development workflows.

Workflow refers to both the process and the tools that are used in this process. Almost every developer comes up with a process of creating and finalizing the project deliverables. This process is implemented through a set of tools that the developer comes up with through trial and error. Once a workflow has been perfected, developers follow the process almost religiously because of a simple reason: following workflows reduces most of the management problems that developers have to face during a project.

[...] Here are some of the PHP ecosystem’s most popular developers and designers, and their tools and/or workflows. Note that these workflows will by no means be comprehensive, but even mentions of tools used by some of the more prominent members of our community should be enough to warrant checking them out.

PHP community members on the list include:

• Taylor Otwell
• Phil Sturgeon
• Nicolas Grekas
• Manuel Lemos
• Josh Lockhart
• Cal Evans
• Kat Zien
• Laura Elizabeth

Each person on the list describes their tools of choice for both development related tasks and how they keep organized. There's plenty of links to these tools and services too for you to check them out on your own.

On the SitePoint PHP blog they've posted a tutorial about the Theory of Constraints, how it can be related back to PHP and what it means for building effective code.

I had been reading The Phoenix Project, a great novel about IT (you read that right), which presents day to day IT and devops problems at a large Amazon-like company in a way which makes mortals understand the complexities and chaos of 21st century technology.

Without giving away any spoilers, at one point in the book the Theory of Constraints is mentioned. [...] The Theory of Constraints can be distilled to the idea that the chain is only as strong as its weakest link.

In the book it was phrased thusly: "Any improvements made anywhere besides the bottleneck are an illusion." For some reason, this resonated with me much more than the chain idiom. There’s just something about building something that’s ineffective that’s more relatable to me than breaking something that’s weakly built.

He goes on to talk about the subject of "factories" and "browsers", relating work done (or not done) on browsers to a factory where throughput of work isn't optimized. He then applies this back to PHP, mentioning some of the tools that can help optimize your workflow to prevent the same kind of factory backlog. This list includes services like Blackfire, XDebug and MySQL optimization techniques.

The Laravel News site has posted a tutorial that offers some advice on how to prioritize fixing bugs and errors in your applications.

One major problem is that prioritizing errors isn’t always clear. Figuring out how much negative impact a bug is really causing is important to answer because not all bugs are worth fixing.

That’s why having a solid workflow in place for prioritizing bugs is so important. In order to confidently allocate your engineering resources on bug fixes and feature building, you need to understand the scope of each application error, and its impact on your customers. Then you can definitively say particular bugs are high enough priority that they should be scheduled into a sprint alongside your work on building new features.

The article is then broken down into a few different sections, each with a few points underneath:

• Get setup with smart error reporting from the start
• Focus your error inbox to keep it actionable
• Prioritize the most relevant errors first
• Prioritize errors by moving them into your debugging workflow

The post is sponsored by Bugsnag so there's some of the content that suggests using their service but the advice is sound for any kind of error handling workflow.

On the Tighten.co blog they have a new post that aims to help you get the most out of the Laravel command line tool's (artisan) tinker command.

Laravel's command line tool is called "Artisan," and it comes with a few powerful features out of the box. Tinker, accessed via php artisan tinker, is arguably my favorite Artisan command. It speeds up my workflow and allows me to interact with my application in ways I would have never thought possible.

Tinker is a REPL (read-eval-print loop). A REPL gives you a prompt that allows you to interact with your application using your language's native syntax (in this case, PHP) in a command-line style.

The post then walks through some of the "hidden features" this command line tool offers including:

• basic usage to call Laravel code (like getting all posts using Post::all)
• a more interactive version of dd(), a debugging tool
• improving speed on a Laravel Dusk testing workflow
• direct access to the PHP docs

The post ends with a few other smaller things this helpful tool can do like showing a stack trace, listing the command history and re-throwing the last exception.

On the Laravel News site there's a quick post showing you how you can use the Alfred tool to manage your Forge created servers. Alfred is a productivity tool for OSX systems that makes it easier to create shortcuts and interface with external applications in a convenient way.

Since the release of the Forge API developers have started creating a lot of apps and integrations, as well as an unofficial SDK. For those that use Alfred on the Mac, Vince Mitchell, launched a Workflow so you can quickly run many Forge commands right from your desktop.

The post includes the list of commands that the workflow includes allowing you to perform operations like opening the server's page in a browser, rebooting a system and restarting the web server on a specific machine. You can grab the workflow from the Packal site and drop it into your Alfred installation for immediate use.

Fabien Potencier has continued his series looking at Symfony 4 with a new post to his site today. This time he focuses on workflow automation and removing some of the daily application management tasks.

Symfony 4's most "innovative" feature is the way it drives the day-to-day application management. No more tedious copy/paste from README files. No more boilerplate code. Automation to the max. On a curated list of Composer packages.

He starts the post talking about Symfony Flex (the main engine behind Symfony 4) and how it can help with package management and installation/integration. He uses the sensiolabs/security-checker package as an example, showing how Flex understands the package and knows to run the checks on future composer install commands. He then digs into other areas Flex helps with:

• bundles
• configuration
• environment variables
• makefile tasks
• Composer scripts

...and a few others. Examples are provided for each of the sections in the composer.json configuration and the post finishes with an example of the full configuration file, putting everything together.

In a previous article on the SitePoint PHP site a workflow was presented for creating and releasing Laravel packages. In this new post from author Younes Rafie an alternative flow is proposed that takes a little different approach.

Every framework gives developers a way to extend the system using packages / extensions. We can generally hook in our logic at any point where we want to provide specific functionality, and Laravel is no exception! Following the article of my fellow author Francesco Malatesta about his Laravel package development workflow, I noticed that mine is a bit different and I wanted to share it with you!

To help illustrate the flow, Younes walks through the development of a two-factor authentication package (presented previously). He then walks through the following steps, giving context for each piece:

• Setting up the Repository
• [Creating a] Package Skeleton
• [Defining the] Package Structure
• [Adding] Tests
• Tagging [the release]

He ends the post with a suggestion not found in the other article: integrating the library with the TravisCI service for continuous integration and verification that all tests are passing.