Martin Hujer has put together a new post to his site sharing some of the PhpStorm plugins he considers essential for Symfony development, making your life easier as you create applications with this popular framework.

I've been using PhpStorm for quite a while and I'm still surprised now and then when it suggests an auto-completion for something I thought that's not possible.

But there are still many things - usually framework- or library-specific - that PhpStorm cannot do on its own. But there are plugins that can step in place and do the magic for specific framework or library.

Several of the plugins are more for improving PHP development in general but others are more Symfony-specific:

• PHP Annotations
• PHP Toolbox
• Symfony Plugin
• PHPUnit Enhancement
• PHP composer.json support
• Php Inspections (EA Extended)
• Twig Support
• .env files support
• .ignore

Each item in the list comes with a brief introduction to the plugin, links to find out more information, and, in some cases, animations of it in use in the editor.

In a new post to his site Tomas Votruba takes the opposite approach to writing good code by sharing bad examples in the form of fourteen tips to write bad code, practices that can make code hard to upgrade and difficult to maintain.

Today I'll show you how to own your company. All you need to do is write code that no-one can read, is hard to refactor and creates technical debt. It's not easy, because if other programmers spot you're writing legacy code, you're busted.

If you keep a low profile of very smart architect and do it right, you'll be the only one in the company who knows what is going on and you'll have a value of gold. Learn how to be successful living vendor lock!

He then goes through his list of poor practices to avoid including:

• Use protected instead of private
• Use Non-String Method Names
• Don't Always use PSR-4
• Hide Your Dependencies in Constructor
• Use Annotations to Define Magic Methods
• Use Traits with Annotations to Define Magic Methods
• Use as Short Naming as Possible

...and many more. For each item in the list sample code is provided so you'll know exactly what to avoid.

On the Laravel News site today Paul Redmond has shared about his own preferred development environment, making use of the Sublime Text 3 editor, and how he has it set up for his PHP development.

While many developers are flocking to IDEs and other hybrids like Visual Studio Code, I’ve found myself trying to create a minimalist Sublime Text 3 setup. I am a minimalist at heart, and I like both my physical environment and virtual environment to be as minimal and tidy as possible.

I want to present to you the minimalist Sublime Text 3 setup that I’ve landed on, but still feel like I have most everything I need to be productive.

He breaks down the article into a few different sections with details for each:

• Built-In Features
• PHP Companion
• CLI Access
• Plugins
• Snippets
• Code Linting

For each item in the list he provides example configuration additions, command line calls, code, and links to the tools he uses.

If you're looking for a good summary of what's coming up in the next major version of PHP (v7.3), look no further than this new post from the Cloudways blog.

PHP is surely giving a tough competition to other scripting languages, thanks to the developers for the rapid updates they unleash from time to time. [...] In the series of these updates, PHP recently has got another milestone with the release of RC1 of PHP 7.3. The version also got some new much-needed updates. While the official release date of PHP 7.3 is given of late December 2018.

In this blog, I will discuss newly introduced PHP 7.3 features and updates.

The post then goes through several of the improvements and new features, providing code examples and descriptions for:

• Flexible Heredoc and Nowdoc Syntaxes
• the PCRE2 Migration
• is_countable function
• Argon2 Password Hash Enhancements
• Same Site Cookie

...just to name a few. There are several others included in the post as well. While PHP 7.3 hasn't been released as a final version yet, you can test these changes out via the current release candidate in your development: PHP 7.3.0RC2. Additionally, more information about the RFCs - including those that weren't accepted - can be found on the PHP wiki.

On the StarTutorial.com site they've posted a tutorial for those that might be newer to the PHP language and ecosystem around it covering the use of Composer. In this latest tutorial they cover some of the basics of using this package manager to pull in and use dependencies in your PHP application.

In general, a block of code forms a method, a group of methods forms a class and a set of classes form a package. A reusable package can be dropped into any project and be used without any need to add functionality to it. A package exposes APIs for clients to achieve a single goal. Packages help our applications achieve DRY (Don't Repeat Yourself), a principle of software development, which reduces repetition of information of all kinds.

[...] In most cases, packages have dependencies. [...] We do need a package manager, a package manager that can solve all of these dependency headaches for us.

The tutorial then goes on to compare two of the main package managers in PHP: Composer and PEAR. It then walks through the installation of Composer and how to use it to pull in a package (in this case the "Faker" package for generating fake user data). It also explains the different commands and configuration files used in working with Composer.

On the Codewall.co.uk site they've posted another tutorial that will help you set up a part of your PHP development environment: XDebug and the IDE NetBeans.

NetBeans is a fantastic free IDE for not just PHP, but other languages like HTML, JavaScript, C++ and more. For PHP it comes highly prepared for being your predominant development environment. It has a whopping list of features that turbo-charge your programming like it’s auto-complete ability to name just one. A PHP development environment isn’t complete unless you have the power to debug the code you write, in this tutorial, you’ll learn how to correctly set that up.

After covering some of the prerequisites they break down the process into a few steps:

• Download XDebug
• Configuring XDebug in the PHP.ini file
• Checking configuration has been activated
• Configuring NetBeans to use the xDebug module

The last step in the process is an example of actually running the debugger and debugging some code with a breakpoint (and the resulting output)

Colin O'Dell has shared an interesting setup he's created to make it easier to switch between PHP versions when testing your code. In his latest post he shows how to switch the version "on cd" (directory change) with the help of some command line shell tooling.

After using phpbrew to manage my local PHP versions for a while, I got tired of re-compiling PHP after every release and decided to install multiple PHP versions side-by-side with Ond?ej Surý's PPA. One of the features I missed from phpbrew was the ability to run a command like phpbrew use php-7.2.8 to automatically change the php command to that version, so I ended up implementing this feature myself using symlinks and shell aliases.

He then walks through his end result, showing the modification of the default php symlink and aliases that can be used to dynamically switch its target. He then includes some examples of how to automate this using your application's PHP version requirements in the composer.json and a simple ZSH script that's triggered on directory change.

Frederick Vanbrabant has a new post to his site sharing some performance tips you can integrate into your PHP code to help improve its overall processing time. He also talks some about a few that are just myths and debunks them.

We’ve all been there before, you submit a pull request and moments later you get a comment like: “Hey you should use a native function here, they are so much faster” or “You can declare this final, that way we save some processing power”.

It’s great that we as developers keep an eye on this, but how true are these thing. And are they still a thing in newer PHP versions?

He goes through a list of ten tricks that have been widely shared and creates some simple benchmarks around their use:

• single versus double quotes
• JSON handling versus XML handling
• speed difference from using layered objects
• native array functions versus loops
• fetching an array item by quoted ID versus just ID
• performance difference of throwing exceptions
• impact of unused variables
• magic methods versus normal methods
• final versus non-final classes
• comments in code

For each of the items in the list he includes the example code he used for the benchmark and the output from the PHPBench tool.

Matthias Noback has posted another article covering domain-driven development practices, this time focusing on testing actual behavior and some of the downsides that can come with it and domain-driven development.

He breaks the article up into three main sections:

• The downsides of starting with the domain model
• The downsides of starting with the smallest bricks
• The downsides of your test suite as the major client of your production code

Each includes a description of the downsides related to the topic and, where it helps, code to illustrate the issue. The post also includes three experiments to try to help prevent some of these downfalls from happening (including not testing constructors and not adding getters).

Tests are not the main use case of an object, they should guide the development process and make sure you write exactly the code that you need. This means not sacrificing the object's encapsulation just to make it testable.

Matt Sparks has posted the latest tutorial in his "Building a PHP framework" series of posts. In this latest article he covers the use of test-driven development during the development of some of the first framework code.

In part 4 we laid the foundation for Analyze. Now it’s time to write the very first lines of code! [...] Essentially, test driven development is a process of writing tests before writing any code, then writing code that passes the tests. [...] If you’re new to TDD, this probably seems pretty weird. Stick with me.

He starts with a brief definition of what test-driven development (TDD) is and what tool he'll be using to create the tests. Next is a simple example of a test that creates a class instance (NumberAdder) and calls an add method on it. This fails because none of this exists yet, hence the "test first" part of TDD. He then goes back and creates the class and method and loads them so the test can use them.