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 Tim MacDonald has written up a post sharing some tips on how you can speed up your PHPUnit tests, making them easier to run and more useful during the development process.

Having a fast test suite can be just as important as having a fast application. As a developer, getting feedback quickly about the state of your code allows for a much quicker development turnaround. Here we are going to run through some tips you can implement today to make your tests run faster.

The example test suites have been made intentionally slow to simulate a broader set of tests and also to emphasize the improvements possible. Your real-world mileage may vary.

He makes recommendations around the use of ParaTest to run the tests in parallel, re-running only failed tests, grouping slow tests, lowering the password hash "rounds" count and disabling XDebug. Each item in the list includes instructions on what changes need to be made and screenshots of the results of the change.

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 Laravel News site there's a new post sharing twenty Eloquent tips for the Laravel users out there.

Eloquent ORM seems like a simple mechanism, but under the hood, there’s a lot of semi-hidden functions and less-known ways to achieve more with it. In this article, I will show you a few tricks.

Among the tips and "hidden features" mentioned are tips about:

• Increments and Decrements
• Model boot() method
• Model properties: timestamps, appends etc.
• Order by relationship
• Order by Mutator
• Raw query methods
• Create additional things when creating a model

...and many more. There's code examples for each of them showing them in use too.

On the Laravel News blog they've posted a tutorial with some helpful tips for improving your routing in your Laravel-based application.

The Laravel router has a great, well-polished API when you first dive into Laravel as a beginner or newcomer to the framework. What follows is not anything hidden or new, but a few tips that should help you when you’re learning Laravel 5.

The documentation is excellent, and the tips that follow supplement and piece together a few parts that will help you get a quick jumpstart on learning how to use routing in your Laravel applications.

The tips include:

• Custom Namespaces
• Route Macros
• Debugging Routes
• Named Group Routes

Each of the tips include the code needed to implement them and a brief summary of why they're useful.

Martin Hujer has written up a guide for the Composer users out there (you do use Composer, right?) sharing seventeen tips for using it effectively to manage the dependencies in your applications.

Although most PHP developers know how to use Composer, not all of them are using it efficiently or in a best possible way. So I decided to summarize things which are important for my everyday workflow.

The philosophy of most of the tips is "Play it safe", which means that if there are more ways how to handle something, I would use the approach which is least error-prone.

His tips include:

• Be aware of differences between a "project" and a "library"
• Use version ranges for libraries dependencies
• Run Travis CI builds with different versions of dependencies
• Do not attempt to merge composer.lock when rebasing or merging
• Update dependencies safely
• You can define other types of dependencies in composer.json

Each item in the list comes with a summary and an example of the configuration related to the tip. Most of them are small tweaks to the configuration you're probably already using but there are definitely some nice "hidden gems" in there.

On the Laravel News site they've posted a guide to help you maximize your terminal productivity by sharing a few tips to help you get the most of out the time you spend at the command line.

This week, we just published some great bash aliases from the community, and I wanted to write more about maximizing your terminal productivity. I’ve coached many developers, and the terminal is often the area I see that many great developers (much better than me) could improve and gain some productivity and better tooling.

After talking about his own first steps as a developer and the tools he used, Paul Redmond talks about the set of helpful tools and software he now uses including:

• the Zsh shell (and Oh My Zsh)
• updating the CD Path
• Using path expansion
• History completion
• History search and execution
• Terminal themes

He ends the post with a few other recommendations of resources to check out and quick tips on sharing the results.

The Laravel News site has posted a tutorial that offers some advice on how to prioritize fixing bugs and errors in your applications.

One major problem is that prioritizing errors isn’t always clear. Figuring out how much negative impact a bug is really causing is important to answer because not all bugs are worth fixing.

That’s why having a solid workflow in place for prioritizing bugs is so important. In order to confidently allocate your engineering resources on bug fixes and feature building, you need to understand the scope of each application error, and its impact on your customers. Then you can definitively say particular bugs are high enough priority that they should be scheduled into a sprint alongside your work on building new features.

The article is then broken down into a few different sections, each with a few points underneath:

• Get setup with smart error reporting from the start
• Focus your error inbox to keep it actionable
• Prioritize the most relevant errors first
• Prioritize errors by moving them into your debugging workflow

The post is sponsored by Bugsnag so there's some of the content that suggests using their service but the advice is sound for any kind of error handling workflow.

The QaFoo blog has posted a new article sharing five tips to improve your unit testing of your PHP applications. Even if you're a testing veteran, there's some helpful hints in here for you.

After you got the hang of unit testing there is still so much space for improvement. In this post I want to share five tips with advanced testers I have seen to influence testing in the right direction.

Their list of five tips includes advice about what you should consider as a "unit", refactoring test code and writing tests for bugs. Each topic includes a brief description of the suggestion and clear steps to follow when integrating it into your testing workflow.

On the Laravel News site there's a tutorial posted from Dmitry G. Ivanov giving you some helpful tips on building your first Laravel package.

Laravel is a powerful and modern framework. It has tons of different features, which make our work faster and easier. But you can’t push everything into the single box. At one time or another, we’ve all been in need of something not implemented in the framework out of the box.

[...] A package can be a solution. Write your code once and use it in any number of projects. Maybe you found a bug, or want to make some changes? Do it just once in your package code and then pull required changes in all of your projects. Sounds good?

The article then breaks down the information into a few different categories:

• The First Step (checking Packagist for something pre-existing)
• Development
• Testing
• Documentation
• Release

He ends the post by pointing out that there's several other things to consider when creating your package but they're a bit more in-depth than a short post like this could tackle.