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

Tomas Votruba has a new post to his site sharing some of the ways you can get the most out of Travis-CI, the popular build service, for your PHP applications.

Travis CI is the most spread CI in checking open-source projects.

Do you want to know how to use it 3x faster? How to make Travis generate code for you? And how to make your tokens safe?

He breaks down his suggestions into a set of seven tips:

• Skip x-debug
• Deliver PR Checks Fast
• Use ENV vars
• Use Travis to do More Just Watching
• Rebuild your GitHub Pages Daily
• Stay Secure
• Make use of Composer Scripts

For each item in the list he includes an example of what's required, either a change in the Travis-CI configuration, code, or in the Composer configuration.

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.

In a new post to his site Colin O'Dell has shared a Composer "metapackage" that can help you avoid unsupported Symfony component versions with the help of Composer's own internal version checking system.

Using symfony/symfony makes Composer install all Symfony Components in the same version. But when using the standalone packages, Composer might install dependencies in a different major version - for example, symfony/validator v2.8 is compatible with symfony/translation v3.0.

This is fine if you don't want to stick strictly to Symfony LTS versions, but it does mean that you could end up using versions of components which no longer receive security updates.

Rather than having to specifically define (and manage) the versions of package you want to install, you could opt to install his package that will do the hard work for you. It uses the "conflict" handling in the Composer configuration to limit version numbers on many of the popular Symfony packages and requires them to be greater than or equal to certain versions.

The Delicious Brains site has continued their series covering WordPress deployment with part three: Deploying WordPress Using Git. While their instructions relate to WordPress, the examples given would work for any PHP-based application.

In my last article, we looked at deploying WordPress using some different command line (CLI) tools. In this article, we’re going to look at how we can deploy WordPress using Git, both manually via the CLI and also automatically when you push code to your remote repository.

They start by listing out the tooling you'll need to follow along - Git and Composer - and an example repository you can work from. The post then walk through three different methods you can use to deploy making use of Git:

• a "git pull" on the production server
• automated deployment via webhooks
• deployment using a continuous integration service

For each item there's a brief summary included as well as configurations, screenshots and setup instructions.

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.

On the Symfony blog there's a post covering some of the recent improvements in the framework that can help to make creating and updating Symfony projects faster via some recent changes speeding up the Composer installation.

A few years ago, we introduced the Symfony Installer as the fastest way to create new Symfony projects. While Composer took up to several minutes to create a new project, Symfony Installer did the same in less than ten seconds.

The trick was that the installer downloaded a ZIP archive with all the dependencies required by the specific Symfony version you were installing, so it was not necessary that Composer resolved the project dependencies.

However, with the release of Symfony 4 we deprecated the Symfony Installer in favor of Composer, because we wanted to use standard development tools as much as possible. Sadly this made creating new Symfony projects slower and, in some cases, it triggered "out of memory" exceptions while Composer was resolving the dependencies.

The post talks about the changes they made to the Composer installation process, mentioning the two major changes: including a composer.lock to prevent version resolution and removal of all legacy Composer tags. They also share some benchmarks for the installation both before and after the changes showing a jump of at least ten seconds post-changes.

On the TutsPlus.com site, they've posted a new tutorial showing you how to use one of the more popular (and longest running) mailer projects in PHP: Swift Mailer. In this tutorial they introduce you to the tool and share some code showing it in use to send basic emails.

In this article, we're going to explore the Swift Mailer library that allows you to send emails from PHP applications. Starting with installation and configuration, we'll go through a real-world example that demonstrates various aspects of sending emails using the Swift Mailer library.

The article starts with a brief introduction to the Swift Mailer library and what kinds of features it brings to the table. It then shows the installation via Composer and how to include it into your application (autoloaded, naturally). Code is then provided showing how to send emails and includes examples of sending BCCs, attachments, setting the "from" and setting the body contents. It steps you through each part of this sample code and explains what it is doing and other options it could include.

Rob Allen has posted a quick tutorial to his site showing how to user Composer in a PHP project on OpenWhisk. OpenWhisk is Apache's serverless cloud platform that's easy to scale and relatively easy to use. This is the latest in a series of posts from Rob covering its use in PHP projects.

Every PHP project I write has dependencies on components from Packagist and my Serverless OpenWhisk PHP projects are no different. It turns out that adding Composer dependencies is trivial.

He uses a simple action that coverts a number to the matching string, showing the yaml configuration changes and code to include to define the action. The action makes use of the NFNumberToWord package which is then added via Composer. He deploys the action and calls it directly, showing the result to be the correct string for the number "123". He also mentions an archive file (zip) that the serverless functionality creates containing all of the files related to the project. He shows the configuration option you can use to split these by action, making it easier to create a more modular system.

On the Laravel News site they've posted a tutorial sharing some helpful hints for the Laravel users out there about developing package locally without having to release it and wait to pull the latest version back down.

Developing Composer packages locally through a local file symlink speeds up development immensely when you want to create Laravel packages and try them out on a real application. I was reading about a tagged: laravel package local development tutorial composer

Link: https://laravel-news.com/developing-laravel-packages-with-local-composer-dependencies