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

Jessica Mauerhan has a tutorial posted to her site that covers the five types of test doubles in PHPUnit and how to use them in your tests. Test "doubles" - the most common one being a mock - are useful for simulating resources or other objects required to test units of code without external interactions.

Did you know that a Mock is only one type of a test double? Most of us use the word “mock” to mean any kind of test double, but there’s actually five different types. It really can help you understand what you’re trying to accomplish with your test if you know a little bit more what you’re doing with your test doubles, so this article will explain the kinds of test doubles, when you use them, how you use them and why.

She starts the post with a brief definition of the term "test double" and then covers each of the five with descriptions and example code:

• Dummy
• Stub
• Spy
• Mock
• Fake

While some of the functionality is similar between the types, she defines their differences and the cases where each would be most useful.

On the CodeWall site Dan Englishby walks you through some of the basic functionality in the PHP language for working with arrays. In it he shows how to loop through an array using multiple tools including the usual control structures and others less widely used.

PHP, just like most other programming languages has multiple ways to loop through arrays. The most popular ways to do it usually is with a while, for and foreach operator, but, believe it or not, there more ways to do it with PHP. In this article I will walk-through each possibility for reading arrays whilst looping.

He breaks the article up into sections, one for each of the methods:

• the white loop
• the for loop
• the foreach loop
• the do/while loop
• using the ArrayIterator

Each item in the list comes with a summary of how it works and some code showing it in action.

In a new post to his site Tomas Votruba has shared a list of five things that he, as an open source package maintainer, had heard before getting started.

I wasn't always confident while making public every single line of PHP code I write. I had to take many blind paths, spend a night full of stress coding in unknown waters and make a lot of over-complicated code that backfired to me months later.

They say "experience cannot be passed and it must be experienced" and I agree with that, but still there are some shortcuts that would speed-up my path to joyful open-source coding I have today. Here are 5 of them.

He then shares his suggestions, each with a brief summary explaining what it means and how you can apply it:

1. Be Open to Change any Package
2. Don't Keep Every feature You Have
3. Lock to LTS, Maintained Dependencies and green PHP
4. All You Need to Maintain is 1 Repository
5. Don't Take Advise as Granted, Experiment for Yourself

He includes some of his own backstory in several of the posts about his own development work and how he found out some of these "the hard way".

Matthias Noback has a tutorial posted to his site sharing his thoughts on when adding an interface to a class is useful. Here he's talking about using interfaces as a structure for your application, making it easier to understand and more structured.

I'm currently revising my book "Principles of Package Design". It covers lots of design principles, like the SOLID principles and the lesser known Package (or Component) Design Principles. When discussing these principles in the book, I regularly encourage the reader to add more interfaces to their classes, to make the overall design of the package or application more flexible. However, not every class needs an interface, and not every interface makes sense. I thought it would be useful to enumerate some good reasons for adding an interface to a class. At the end of this post I'll make sure to mention a few good reasons for not adding an interface too.

He then offers five suggestions of cases where an interface makes sense:

• If not all public methods are meant to be used by regular clients
• If the class uses I/O
• If the class depends on third-party code
• If you want to introduce an abstraction for multiple specific things
• If you foresee that the user wants to replace part of the object hierarchy

For each item in the list he provides a summary of the suggestion and some code snippets to back it up. He ends the post with a recommendation about how to handle most other situations where you think an interface might be useful: use a "final" class instead.

Tomas Votruba has a new post to his site sharing five "gotchas" in CLI applications as it relates to the "bin" file.

This post from Master PHP CLI Apps with Symfony cluster will focus on bin files. It's the smallest part of PHP CLI Application, so I usually start with it.

Yet, there are still a few blind paths you can struggle with. I'll drop a few extra tricks to make your bin file clean and easy to maintain.

He starts with a brief definition of what a "bin" file is before getting into his list of "gotchas":

• recommendations about naming and location of the file
• setting it up to be autoloaded by Composer
• including the right "shebang" to have it executed by the correct program
• changing access rights
• symlinking in Composer

The post ends with the complete code required to build a simple Symfony CLI application that will autoload libraries correctly and be executable by the system's php binary.

On the Laravel News site they've shared a list of five useful Blade directives that you may not have known about. Blade is the templating language included with the Laravel framework by default.

We’re going to look at five Laravel Blade directives you can use to simplify your templates, and learn about some convenient directives that make solving specific problems a cinch! If you’re new to the framework, these tips will help you discover the excellent features of Blade, Laravel’s templating engine.

The five on their list provide functionality to:

1. Check if the user is authenticated
2. Check if the user is a guest
3. Include the first view if it exists or includes the second if it doesn’t
4. Include a view based on a condition
5. Include a view if it exists

Each one comes with example code showing it in use and a bit of explanation behind its use.

On the Laravel News site they've posted a new article with a listing of five useful helpers that come standard as a part of the Laravel framework.

There are a ton of helper methods in Laravel that make development more efficient. If you work with the framework, I encourage you to see what helpers you can introduce in your day-to-day work. In this blog post, I’d like to point out a few of my favorites.

The list in the post includes helpers for locating information in an array, pluralizing strings, throwing exceptions based on conditions and accessing object property values. For each item on the list there's a brief explanation and some sample code showing it in action (and what the result ends up being). The post finishes up by linking you over to the helpers page of the Laravel manual for more information and other handy functions to help reduce your own development time.

On the TutsPlus.com site today they've posted an opinion article that tries to help answer the question "Should You Use a PHP Framework?". They provide their own list of top five pros and cons, representing each side and hopefully getting you thinking about your own project.

From routing HTTP requests to accessing the database and rendering the user interface, most web applications have a lot in common with each other. Many of them allow their visitors to sign in, and it's hard to imagine a web application without email sending. A software framework is a way to put this observation into use.

But is using a framework always the best way to go, or does it sometimes make sense just to start from scratch using nothing but plain PHP? To answer the question, in this tutorial, we will look at five pros and cons of using a PHP framework.

Items under their "pros" list include how they allow for more rapid development, easier maintenance in the future and the support of the community around the project. Their "cons" list talks about topics like the more general approach most frameworks take, the lower level of performance vs just PHP and the limited visibility into how the core framework works where it's not supposed to be customized.

On the Toptal.com site author Donald Mudenge has written up a post that wants to help debunk the top 5 WordPress myths that are still floating around about this popular and common tool.

In the early days, people used WordPress only as a blogging tool. However, today WordPress covers more than 50 percent of the market share for CMSs, supporting nearly 60 million websites worldwide.

As a commonly used platform for building websites and other online applications, misconceptions have spread like a forest fire, keeping people away from WordPress. In this article, I outline and explain the five most common WordPress taboos and myths, clarify them and offer solutions on how to overcome them.

The five myths he tries to dispel are:

• WordPress is significantly more likely to be hacked.
• WordPress is just blogging software.
• WordPress professionals are designers.
• WordPress isn’t an enterprise solution.
• One WordPress requires one database.

For each item on the list he includes a brief summary of what's usually said about the myth and corrects it with his own description and links to other resources helping to prove his point.