Tomas Votruba has a new post to his site sharing a listing of some of the more useful and well-established development tooling for PHP and related technologies.

From coding standard tools, over static analysis to instant upgrade tools. This post is going to be a geeky history trip.

Which tool was first? How they build on shoulders of each other?

Are you a lazy programmer who wants to delegate as much work as possible to 3rd party code? Today, you'll become even lazier.

He breaks the article down into three sections, each with several tools linked under them:

• Coding Standard Tools
• Static Analysis Tools
• Instant Upgrade Tools

The items under each link to more information about the tool and provides a brief summary of how it helps you and your code. There's not any examples of them in use, though. You'll need to visit the project's page for more information about that.

Derick Rethans has a new post with his own suggestion about using the right debugging tools to help track down a problem (based on some of his own experience debugging the MongoDB PHP extension).

A while ago, we updated the MongoDB PHP driver's embedded C library to a new version. The C library handles most of the connection management and other low level tasks that the PHP driver needs to successfully talk to MongoDB deployments, especially in replicated environments where servers might disappear for maintenance or hardware failures.

After upgrading a related library, he ended up with a failing test related to Atlas connectivity. He walks through the process he took to try and debug the issue using GDB to see where the execution was failing using various techniques. This included looking through the backtrace and, not noticing anything out of the ordinary, going for a walk. Upon returning he noticed an odd line in the backtrace that, after some additional tracking using a GDB helper, showed the problem to be with how the query options are defined and not reset in a loop.

php[architect] magazine has shared another article from their April 2018 issue on their site. In this article Ondrej Mirtes covers the use of static analysis to help testing and inform you of type safety issues.

When developing an application, our aim as software developers is to make sure it does what it ought to do and to keep the number of defects as low as possible. [...] In this article, I’d like to introduce you to the concept of type safety and how it can improve the reliability and stability of your code. Once your code is more type-safe, and that fact is verified by automated tools, you can cherry-pick which parts of your application need extensive unit tests and where you can rely just on well-defined types.

He starts off by talking about types (strict and dynamic) in PHP and the current state of the typing system for variable values. He covers the role of good type hinting in method and function definitions and how it can help IDEs like PhpStorm locate issues. He also talks about how type hints can provide you feedback on the design of the application and some of the tools that can help you find issues.

He wraps up the article with some tips for making your code more strongly typed and a look at what kind of tests are needed to help ensure these types remain enforced.

The php[architect] podcast, hosted by Eric van Johnson and John Congdon, has posted their latest episode today: Episode #7 - Know Your Tools.

Eric and John dive into the Know Your Tools issue for the month of February 2018.

Topics mentioned in this episode include the contents of the February article, mentions of Drupal, Symfony and Scout as well as a mention of the upcoming php[tek] conference. They also interview Ed Barnard, the author of the magazine's "Education Station" column. You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly. If you enjoy the show be sure to subscribe to their feed and follow them on Twitter to get updates when new shows are released.

Jason McCreary has a post on the Dev.to site sharing what he calls the "debugging golden rule" to keep in mind when stepping through and trying to debug your code for issues.

Developers, especially new developers, often forget this when debugging. We jump into the debugger. We add tracing statements. We review the commit log.

Such actions can be misguided. Before debugging the code we must follow a moral code. Debugging needs a Golden Rule. A rule to remind developers of a few important facts of debugging.

Boiled down to its basics the "golden rule" here is that, most of the time, it's not the tools that are the issue - it's you and your code. He shares the common thoughts we've all had when debugging ("it's the upgrade, not my code") but points out that, regardless of where the issue is, it still needs to be fixed. Even if it is something in the tool, some odd bug or weird functionality that only kicks in once in a blue moon, you still have to ultimately make it work.

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.

Freek Van der Herten has a post on his site sharing a new package that's been developed to help optimize images using some PHP and a few other helpful tools.

Our recently released image-optimizer package can shave off some kilobyes of PNGs, JPGs, SVGs and GIFs by running them through a chain of various image optimization tools. In this blog post I’ll tell you all about it.

He starts off by talking about why they built the package - to make sure the images on their site were as optimized as possible - and what kind of tools are involved in making it work. Those tools are free to use but it does take a little manipulation to ensure the right data is being passed into each. He then gets into the code examples, showing how to optimize an image with just a few lines. The package determines based on the kind of image which optimizing tool to use. He also includes example code showing how to customize the optimization process with extra command line flags. Finally he includes an extra section showing how to integrate it with some of their other packages: the image package, laravel-medialibrary and Browsershot.

As you write your PHP code, you'll need to verify that everything is working as expected and that the code follows all style and formatting requirements. In this list from the SitePoint PHP blog they give you a list of eight tools you can use to ensure all of these criteria are met.

For shipping quality code, we must have testing in mind while coding (if not doing TDD). However, with the wide range of PHP testing tools out there, it’s hard to make a choice! Exploring PHP is a fun adventure (premium course on that here!) but it’s hard to assemble a toolbelt that’s not too heavy to wear to work!

This popular article will highlight the most popular testing tools and has been updated to reflect the state of QA tools in 2017.

Included in their list are tools like:

• PHPUnit
• Cucumber
• Selenium
• Kahlan
• php_testability

The post ends with a brief look at continuous integration and how they can help execute these tools automatically when code changes or before production builds are deployed, taking most of the burden off of developers to remember.

In this post to the bitExpert blog Stephan Hochdörfer shares some updates to his own opinions on the "require-dev gone wrong" problem he previously posted about. In this new post he points out that, while there is an issue here, it's not something that can't be resolved (or has been to some extent).

The gist of all this is that, yes, we do have a problem. Fortunately, there are already solutions out there - none of them perfect, but there's always room for improvement isn't there? Installing .phars with Composer is currently not supported out-of-the-box by Composer but there are 2 projects to help us deal with it: One is tooly-composer-script - a Composer plugin that manages to pull .phar files from a remote location. The other one is PHIVE - the PHAR Installation and Verification Environment.

He points out that, while these two packages help the situation, there's still another "require-dev" issue with tools that don't actually "touch" the code. This requires that a certain version of the tool be run against a certain version of your code, creating a dependency of a different kind. Fortunately there's also a tool to help some with this as well, the php-scoper project that makes it easier to isolate functionality through randomly generated namespaces.