In a new post to his blog, Leonid Mamchenkov has linked to a resource that aims to help developers refactor their code to use best practices and design patterns: Refactoring.Guru.

Refactoring.Guru is a great resource for learning about refactoring best practices and design patterns. A lot of the website’s content is also available as Dive into Design Patterns ebook.

Today I came across this GitHub repository, which makes this resource even better specifically for PHP developers. Yup, that’s right, the GitHub repository features all code examples written in PHP 7.3, making it super easy to jump into coding.

The repository includes a Composer configuration to pull in some analysis tools and includes examples of about twenty different design patterns in use.

Tomas Votruba has put together a new post with a list of five helpful hints for working with GitHub in your development projects.

The best programmers aren't the smartest in the field. They're lazy, they know their tools well and they know good tools other programmers don't.

Do you know the following tips?

His tips include using single-character console command aliases, receiving notifications only when a new package release is made, and the use of the refined-github browser (Chrome/FireFox/Opera) to help reduce required clicks. He also shows how to implement Composer "scripts" for use on the command line - a very useful extension to your Composer configuration.5 Tips to Effective Work with Github Repository

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 Matthew Weier O'Phinney shares some notes about GraphQL usage that he's gathered over the last week or so of working with it.

The last week has been my first foray into GraphQL, using the GitHub GraphQL API endpoints. I now have OpinionsTM.

The promise is fantastic: query for everything you need, but nothing more. Get it all in one go. But the reality is somewhat... different.

He talks about his experience working with the results and the amount of data manipulation that was required to actually get at what he wanted. He shares the query he used, the result the API provided and what he ultimately wanted. He also mentions the less than useful documentation, issues with pagination and an update based on comments of pulling data from the GraphSQL API versus the REST API.

In a post to his site Freek van Der Herten shares some functionality that Spatie uses to help keep the stale pull requests under control across their 180+ repositories: a Botman-based bot that assesses the last updated date and closes after a given amount of time.

At Spatie we have over 180 public repositories. Some of our packages have become quite popular. We're very grateful that many of our users open up issues and PRs to ask questions, notify us of problems and try to solve those problems, ...

Most of these issues and PRs are handled by our team. But sometimes those issues and PRs become stale. [...] That's why we created a bot that can automatically close stale issues and PRs. Here's [an example] of the bot in action.

He then shares the code they currently use for the bot, making use of the BotMan package as a base and the knp-labs/github-api package for the GitHub interaction. The code includes the GitHub service provider, a client class, an Issue object and the command that's run to find and close out the stale pull requests and issues.

On his "Tech Notes" blog Nathan Dench has put together a listing of some of the interesting things that happened in the first part of 2018 in the PHP community.

I organise the a post from Marcel Pociot about the GitHub statistics for various PHP projects

news around Symfony, Silex and Laravel

There's also a few other "random things" to finish off the post with links to other interesting articles, projects and tools.

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 TutsPlus.com site there's a tutorial posted showing you how to get a Laravel application up and running quickly using the combination of GitHub, Linode and RunCloud.io.

If you are a PHP programmer working with the Laravel framework, I am sure that you deploy your web application on cloud servers on providers like Linode, Digital Ocean, Vultr and the rest. That’s because with a framework like Laravel, which works tightly with tools like Git and Composer, it is less and less likely that your application can be served from a shared hosting environment.

This article will show you how to set up your web server for your Laravel application on Linode cloud hosting using the RunCloud.io server management tool.

They then walk through the process of setting up a server on Linode including instance creation and Ubuntu image deployment. Once this is up and running, they take you over to RunCloud.io to connect your account to the Linode server (by IP address). Once the command is executed to link the two, they then show how to create the virtual host for your application and configure the deployment, DNS, domain name and SSL settings. Finally it shows the connection between RunCloud.io and GitHub, deploying the code when a git push action is taken.

Marcel Pociot has written up a post to finish out 2017 and provide a year in review for the community and language via some Github statistics.

It's this time of the year again - the end of the year is coming up fast, so why not step back and take a look at what we, as a PHP community, have achieved this year?

For these statistics, I used the free GitHub Archive data in combination with Google BigQuery, which lets you process 1TB of data per month free of charge.

So let's take a look at some numbers

He first breaks it up into three main categories:

• most starred PHP repositories
• most starred new PHP repositories
• most contributed PHP repositories

From there he "digs deeper" and looks at the packages requiring the most dependencies and graphs the frameworks according to how many dependencies they require to install.

On the Delicious Brains site there's a new post from Gilbert Pellegram announcing serializededitor.com, an editor specifically designed to help visually edit serialized PHP data.

I recently built a command line daemon in PHP to emulate AWS SQSD for the purposes of testing in Mergebot. As it turns out, one of the benefits of building a large, complex product like Mergebot is that there are pieces of the system that we need to build for the project that might be of use to other developers.

Today, we’re launching that system piece, a free online visual editor for PHP serialized data as serializededitor.com.

In this article, I’ll explain how and why we built this “side” project and how I overcame some of the challenges I faced when building this project.

He starts off with the problem they were trying to solve when creating the editor, mostly centered around determining the differences between two pieces of serialized data. They found something similar to what they were wanting but it didn't provide the "easy editiing" functionality they wanted. He then goes through some of the issues they bumped up against along the way: working with the data and PHP's unserialize, the creation of their own parser, the work to create the Vue.js frontend and re-serializing the data once complete.

They've also open sourced the project over on GitHub so you can clone it locally and contribute back.