Freek Van der Herten has a tutorial posted to his site sharing some customizations you can make to PHP code generation in PhpStorm to fix some issues he's noticed in his own development work in the IDE.

I've been using PhpStorm for quite some time now, but never took the effort to fix a few minor annoyances I had with it.

He shows how to change the generation for:

• Getting rid of the default comment for new PHP files
• Compact docblocks for instance variables
• Fixing the placement of the caret
• Using fully qualified class names in doc blocks
• Changing the default visibility

The final item in the post isn't so much a code generation change as it is a tip for saving these changes and your other configuration options. He shows how to back them up on a git repository out on GitHub.

On the AWS Developer blog they've posted about a new update in their PHP SDK functionality: a "changelog builder" that helps with automated changelog generation.

Starting with version 3.22.10 of the AWS SDK for PHP, released February 23, 2017, the Changelog Builder automatically processes all changelog entries. Each pull request is required to have a changelog JSON blob as part of the request. The system also calculates the next version for the SDK based on the type of the changes that are defined in the given changelog JSON blob.

The update simplifies the process of adding release notes to the CHANGELOG.md file for each pull request. Each merged pull request that was part of the release results in a new entry to the CHANGELOG.md file. The entry describes the change and provides the TAG number and release date.

This changelog is generated from a required JSON document for each pull request that provides information about the type of change, category and a brief description. They explain each of these items to give a little more context as to what they should contain along with a few examples.

This is something that could definitely help to improve other libraries as well, gathering the required change information from the contributor rather than having a project administrator have to sift through the PR to locate all changes.

On the CloudWays blog there's a new tutorial posted showing you how to create project documentation with Sami, a tool that takes the DocBlock information already in your code and makes it into something more human-readable.

Developers regularly create large blocks of code that form parts of API’s and other mid to large level projects. While there is a (more or less) agreed upon convention for code writing, every developer has a personal comment and documentation writing standards. Some add small cryptic notes while others attach full-length Google Docs that document the method or class in painful details. This problem becomes very severe when the number of end users increases and there is a need for proper documentation of the project.

[...] DocBlocks are important because they are used by a well known Symfony document generator package called Sami. Very popular in PHP community, Sami also provides the ability to create custom twig templates and work with versioned documentation on GitHub. In this article, I will use Sami and a GitHub project Sync Mysql data with Elasticsearch to automatically generate documentation.

The tutorial then helps you get the Sami package installed via Composer and how to execute it to ensure it's working as expected. Next it points you to a project to clone to help with the MySQL-to-Elasticsearch interface. It then helps with the creation of a configuration file, the results of a build and some additional tips for customizing the configuration for your environment.

On the PhpStorm blog (from JetBrains) Gary Hockin reflects on a post from Adam Wathan with tips for combining PHPUnit and PhpStorm for more effective debugging.

Community stalwart and Laravel aficionado Adam Wathan blogged on his PHPUnit workflow in Sublime text.

Gary then goes through the points in Adam's post and shows how they can (mostly) be accomplished directly in PhpStorm:

• Generating unit test boilerplate for a class
• Using "snippets" to create shortcuts for reusable code
• Running the tests in just one file directly from the IDE

Each section comes with a brief description and animated screen grabs showing the flow of the setup and use for each.

The SitePoint PHP blog has a post from author Nicola Pietroluongo talking about randomness in PHP. In the tutorial he talks about randomness, how it relates to cryptography and what's coming in PHP 7 to help.

This article analyzes problems related to random number generation used for cryptography purposes. PHP 5 does not provide an easy mechanism for generating cryptographically strong random numbers, while PHP 7 solves this by introducing a couple of CSPRNG functions.

He starts off by talking about what a CSPRNG (cryptographically secure pseudorandom number generator) is and some of the things it could be used for. He then moves on to the functionality coming in PHP 7 with the addition of the random_* functions for getting random bytes and random integer values. He talks briefly about what's going on "behind the scenes" of the generation and provides a simple code example with a randomized "dice roll" and the resulting numbers. He ends the post mentioning the random_compat library that can be installed for pre-PHP 7 applications that provides the same functionality just without those two functions defined.

In this post to the HHVM blog they answer a common question they get from the development community: why don't they use LLVM for code generation when compiling down the PHP.

The primary reason has always been that while LLVM is great at optimizing C, C++, Objective-C, and other similar statically-typed languages, PHP is dynamically typed. The kinds of optimizations that provide huge performance benefits for static languages tend to be less useful in dynamic languages, or at least overshadowed by all the dynamic dispatching that’s done based on runtime types. We knew that there was probably something to be gained from using LLVM as a backend, but there were many larger opportunities go after first.

They talk about the compilation pipeline HHVM uses and shows the difference between how it works versus how LLVM would integrate into the final steps. They also talk about the work put in to explore the use of LLVM IR and what kind of changes they had to make to support it. This includes updates to PHP function call handling, generalizing vasm and updates to the LLVM tool itself (with changes to location records, smashable calls and performance tweaks among others).

The Paragon Initiative blog has posted a guide to what they see as a way to safely generate random strings and integers in PHP applications.

Generating useful random data is a fairly common task for a developer to implement, but also one that developers rarely get right. [...] It's generally not okay to use a weak random number generator unless both of the following two conditions are met: the security of your application does not depend in any way on the value you generate being unpredictable or there is no requirement for each value to be unique (up to a reasonable probability).

He gives some examples of places where it's a must to use a "cryptographically secure pseudo-random number generator" including generating random passwords, encryption keys or IVs for data in CBC mode. The article goes on to talk about some of the problems that could come from using weak generators. It then gets into the process for generating random values and the use of the random_* functions in PHP (or using this polyfill) to more safely generate the numbers. Included is code showing the process and some advice around converting random bytes to both strings and integers.

The SitePoint PHP blog has a new article posted sharing four of the best charting libraries they've seen for use in your PHP applications. Options include both server and client side tools, making finding one for your situation easier.

Data is everywhere around us, but it is boring to deal with raw data alone. That’s where visualization comes into the picture. [...] So, if you are dealing with data and are not already using some kind of charting component, there is a good chance that you are going to need one soon. That’s the reason I decided to make a list of libraries that will make the task of visualizing data easier for you.

He starts with a brief comparison of the server side versus client side options, pointing out some high level advantages and disadvantages of each. He then gets into each of the libraries, giving an overview, an output example and some sample code to get you started:

• Google Charts (Client Side)
• FusionCharts (Client Side)
• pChart (Server Side)
• ChartLogix PHP Graphs (Server Side)

He ends with a wrapup of the options and links to two other possibilities you could also evaluate to find the best fit.

On the SitePoint PHP blog today there's a new post showing you how to create PDFs in a Drupal-based site making use of the Print module for the creation and formatting.

DF generation takes a slight change of mindset. As web developers, we have spent a lot of time convincing designers from a print background to stop producing pixel perfect designs that will be difficult to reproduce on the web. If you want to introduce PDF generation or any form of high designed print output, then we need to relearn some of our old skills we left behind. The nature of print means that it is precise and often needs pixel (or millimeter) perfect design.

He'd initially thought that the Views PDF module would be the natural choice, but after finding some unwanted dependencies, opted for the Print module instead. The Print module only creates the formatted output, though. This is then passed off to wkhtmltopdf to convert into final PDF form. He walks you through the configuration for the Print module and how to create some of the basic HTML structure for the resulting output. Next up is the addition of some styling and the process for exporting the HTML output over to wkhtmltopdf for handling. Output samples are included to help illustrate the final result.

On the main PHP.net site today there's an announcement posted about the working being done on the next generation of the PHP language based on some recent discussions (and actual development work). The PHPNG branch helps boost the performance of the language to new levels and cleans up some of the core APIs.

When we aren't looking for pictures of kittens on the internet, internals developers are nearly always looking for ways to improve PHP, a few developers have a focus on performance. Over the last year, some research into the possibility of introducing JIT compilation capabilities to PHP has been conducted. During this research, the realization was made that in order to achieve optimal performance from PHP, some internal API's should be changed. This necessitated the birth of the phpng branch, initially authored by Dmitry Stogov, Xinchen Hui, and Nikita Popov.

The post talks about the performance increase of these changes (an average of 20%) and the current progress made on the internal project. This is "only the start" of the work on this new functionality, so keep an eye on the PHP.net site for more upcoming details.