On the Contentful blog they've posted the second part of their series reviewing static site generators for PHP. In this new article they look at Jigsaw, a Laravel-based tool.

In the first article of the series we took a look at Sculpin, the PHP static site generator which is currently the most starred on Github. Today we’re exploring Jigsaw, a tool which promises to bring a Laravel-based approach to the world of PHP static site generators (SSGs).

The author starts by sharing some about his (somewhat limited) experience with Laravel. From there he dives right in, showing the creation of a new Jigsaw site including configuration and how to serve it up locally. It then gets into detail about the directory structure of the site, asset handling and adding new content. The post ends by answering the "is it ready" question for their own needs (at Contentful).

The Exakat blog has an interesting post to their site sharing some statistics from the applications they've scanned related to commonly used coding styles. In this PHP Index of Coding (for 2018) they share a listing of practices in the order of popularity according to the results of over 1700 projects.

Not using @ is the poster child of good practices. It’s also looked upon, as an impossible goal. Did you know that the @ operator is only merely used by 50% of PHP applications ? Same for parenthesis with include (and co) : don’t use them, like 50% of the developpers. This is how the Exakat PHP Index of coding was born.

Every month, Exakat runs thousands of analysis on half a billion lines of PHP code. This is primarily for testing purpose, a kind of torture test that checks the engine runs on any kind of code. And it is very useful to ensure all situations are correctly handled.

We also extracted the following stats out of 1700+ projects, analysis by analysis. This way, any issue may be ranked from ‘wide spread’ to ‘very unusual’. In fact, ‘wide spread’ may also be understood as : ‘almost a feature’.

The results are ranked by frequency of appearance with the top five being:

• Uses Default Values
• Used Once Variables (In Scope)
• Unused Methods
• Method Could Be Private Method
• Should Use Local Class

For each item in the list there's a link to more information about the check and how much it has changed since the last time the index was generated.

On the Symfony blog they've posted an update about recent advancements in their diversity initiative. They share a few different updates, resources and changes that have been made to help improve the overall diversity of the community around this popular framework.

Updates included in the post cover:

• Respectful Review Comments (a guide on writing them)
• Mentorship program
• Code of conduct and enforcement process
• Context and Slack discussions
• New slack channels

The post ends with a few "final words" from Lukas Kahwe Smith about another initiative that's been started to help improve the representation from specific groups in the Symfony community and ecosystem.

As is mentioned by the Laravel News site and announced on the GitHub blog, repositories that have PHP have a new feature - introspection showing what methods and functions have changed in pull requests.

The file finder makes it easy to review pull requests and understand how changes impact your code. Now PHP developers can navigate to changed methods and functions right in their pull requests, too.

Searching the file finder for the term function or the name of a changed function in a PHP file will provide you with a filtered view of the results, so you can easily identify and view the most impactful parts of a pull request. Check out the documentation to learn more.

An animation in the post shows the feature at work, making use of the "Jump to" menu to show a drop-down listing of all files changed and the methods changed inside them. These can then be used to jump to parts of the pull request (rather than having to search through the entire thing for changes).

On the SitePoint PHP blog editor Bruno Skvorc has posted a tutorial showing how to combine Git and WordPress to make it easier to update posts on the site via pull requests.

At Bitfalls.com, we also use WordPress for now, and use the same peer review approach for content as we do at SitePoint.

We decided to build a tool which automatically pulls content from merged pull requests into articles, giving us the ability to fix typos and update posts from Github, and see the changes reflected on the live site. This tutorial will walk you through the creation of this tool, so you can start using it for your own WordPress site, or build your own version.

He starts by outlining the plan for the process including some of the functionality that will be put to use - like WPGlobus and Markdown files. He then walks you through the creation of an environment for the end WordPress installation (for testing), creates the webhook on the GitHub side to handle the push and the code needed to grab the content and push it into WordPress. He also includes an example of the workflow, showing a PR being created and merged to ensure the flow is functioning as expected.

On the SitePoint PHP blog there's a new tutorial posted from editor Bruno Skvorc looking at PHPBot, a chatbot tool that might help you look up PHP documentation questions a bit more easily (and quickly).

I came across PHPBot the other day (not to be confused with Botman or Fondbot) – a “chatbot” which helps you look up PHP manual entries and generates example code for them.

If you follow me on Twitter, you know I don’t believe in chatbots being chatbots – as someone who’s built some for both commercial purposes and personal ones, and as someone who was around in the age of IRC auto-responding scripts, I see chatbots as a little more than a marketing fad designed to impress today’s Snapchat generation. However, every now and then one will appear that’s actually useful. Could this be the one? Let’s take a look.

He starts off with some of the basic concepts behind the bot and examples of some of the output from documentation requests. He goes on to talk about the actual usefulness of the bot and provides some instances where it is still lacking in functionality. He also looks at several other subjects including Knowledgebase and Bugs, Autocompletion / Suggestion and Copy / Paste Friendliness.

On the BitExpert blog Stephan Hochdöfer has written up a post showing how to "Dockerize" GitLab review apps to create a consistent platform for these self-contained environments.

Last year GitLab introduced the Review Apps feature. Review Apps are app environments that are created dynamically every time you push a new branch up to GitLab. As a bonus point the app environments are automatically deleted when the branch is deleted. Since we moved to using docker for quite a few of our projects I was keen on figuring out how to combine Docker and the GitLab Review Apps functionality as the documentation only mentions NGINX as a way to run Review Apps. As it turns out, it is rather simple to deploy docker containers as a Review App.

He describes the environment he needs and which tools he'll be using to perform the build of the environments. He then defines the sample GitLab configuration file including the "build" stage. He briefly explains the steps this follows then shows the configuration for the "deploy" step, grabbing the latest image from his Docker repo and running it. He ends the post with an "undeploy" stage that removes the Docker build automatically when the environment is no longer needed.

Ian Cambridge has put together a new post for his site focusing on the Single Responsibility Principle, one of the more well-known (and well understood) parts of the SOLID design principles.

Single Responsibility Principle (SRP) is probably one of the most well-known principles from SOLID. At its core is a desire to prevent classes from becoming overwhelming and bloated. While enabling the ability to change how a single thing works by only changing a single class. So the benefits of SRP are that you have an easier codebase to maintain since classes are less complex and when you wish to change something you only have to change a single class. In this blog, I will go through some ways to try and help avoid breaching SRP while doing code review.

He gives two examples and the code they might contain, breaking the SRP mentality. The first is a "manager" (or service) class that, while good in principle, usually ends up performing way too many operations than it should. The second is a "from usage" instance where the return of one method is being used as a parameter for another method in the same class. For each he talks about the problem with the current implementation and offers a suggestion or two of things to fix to make it adhere more to SRP ideals.

The Laravel News site has posted a book review by Diaa Fares of Adam Wathan's "Refactoring to Collections" book.

“Never write another loop again.” A strong promo sentence used by Adam Wathan to market his Refactoring to Collections book, but does it hold the promise? Well, together we will explore how close that claim is to reality.

If you are a Laravel developer, chances are you’ve heard about the collection pipeline before. While I use it a little in my projects I hadn’t realized the possibilities of this approach until I read Refactoring to Collections. It brought me to another level of thinking about utilizing the power and capabilities of functional programming.

The review goes on to talk about imperative versus declarative programming (with examples) and how the book walks you through "the journey" to move to a collections-driven code structure. The review also points out the amount of concepts to learn in the book and the style/effort that was clearly put into its creation. It also points to this RFC as hope for the native use of "arrow functions" in PHP in the future.

Giorgio Sironi has posted a review of a book to his site that shares fifty quick ideas to improve your tests that can help with things like run time, ease of maintenance and following best testing practices.

Fifty quick ideas to improve your tests is, well, a series of fifty quick ideas that you can implement on some of your automated test suites to improve their value or lower their creation or maintenance costs.

These ideas are pattern-like in which they are mostly self-contained and often independent from each other. They are distilled from real world scenarios that the authors (David Evans, Tom Roden and Gojko Adzic) have encountered in their work.

He's included a few quotes from the book he found particularly interesting including mentions of:

• a pyramid of software quality levels
• misunderstanding that testing can somehow be completely replaced by a set of carefully chosen examples
• difficult testing is a symptom, not a problem
• the problem with time-based "sleeping" in tests

You can find the book itself over on Leanpub and can pick up your own copy for around $10 USD.