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

Matthias Noback has continued his series of tutorials covering various uses of the Repository design pattern. This is the second part of the series and picks up where part one left of, showing the handling of entities in the repository, performing the usual CRUD operations.

In part 1 of this short series (it's going to end with this article) we covered how you can test-drive the queries in a repository class. Returning query results is only part of the job of a repository though. The other part is to store objects (entities), retrieve them using something like a save() and a getById() method, and possibly delete them. Some people will implement these two jobs in one repository class, some like to use two or even many repositories for this. When you have a separate write and read model (CQRS), the read model repositories will have the querying functionality (e.g. find me all the active products), the write model repositories will have the store/retrieve/delete functionality.

In particular if you write your own mapping code (like I've been doing a lot recently), you need to write some extra tests to verify that the persistence-related activities of your repository function correctly.

He starts with the test cases for the functionality (following the test-drive design mentality) and talks about the expected behavior of the various entity and repository methods. He includes the code for these tests covering state changes, handling child entities, deleting entities, and working with ports/adapters.

Matthias Noback has kicked off a new series of posts on his site covering the use of the repository design pattern in different situations. In this first post he focuses on "test driving" classes for handing database queries and their results.

A test for a repository can't be a unit test; that wouldn't make sense. You'd leave a lot of assumptions untested. So, no mocking is allowed.

[...] But how do you test everything that is going on in a repository? Well, I found out a nice way of doing so, one that even allows you to use some kind of test-driven approach. In this article I'll cover one of the two main use cases for repositories: querying the database, and returning some objects for it. The other use case - storing and loading objects - will be discussed in another article.

He starts by getting everyone on the same page with a definition of a "query" and how it relates back to a repository class. He then walks through the process of how to test the class, first as a general "get all" query then with a check on the "active" state. Once the test goes green (successful), he adds more variations to both the tests and fixtures. There's not a lot of code examples in this post but it does show some good concepts to get you headed down the right path.

The Pehapkari.cz site has continued their series on domain-driven design with their latest tutorial covering the use of a repository for handling instances and collections of objects.

We will discuss how to store and read domain objects while pretending we have an in-memory system. Simply, we will show how to implement and test repository.

The article starts with a look at collections and the reality of using them outside of an in-memory environment. It then focuses in on the idea of a repository that live in the domain layer and some of the responsibilities they have as a part of the overall system. With the basics defined the tutorial then gets into the concrete implementation of the repository and how to write effective tests to ensure its correct functionality.

Barry van Veen has a quick post on his site showing the Composer users out there how they can use a package from a local directory without having to go through the hassle of pushing it and adding it to Packagist.

Suppose you run a website and want to split part of it into a package with its own repository. You start a new repository and check it out on your development machine. But now you want to see how the website and your new package integrate. How to go about this?

This article explains how you can require a package from a local path into your project with Composer. This way you can run a local copy of a repository and test any changes you make. Because the local repo will be symlinked changes are shared in real-time, there is no need for intermediate committing and updating.

He shows how to update your composer.json configuration's repositories section to add an entry with a "type" value of "path". This then points to the location on the filesystem where the package resides. Then it's just a matter of requiring the dev-develop branch and the code will be treated just like any other package. He also includes a section showing how to handle things when symlinking fails, a problem that usually happens on Windows for VM users. Usually it's related to a permissions error for whatever user is running the VM.

In a post to his site Andreas Möller shares a tool that he uses to get an application up and running quickly, providing a makefile for lazy developers.

Whatever the size of the software project, I believe in, subscribe to, and promote Continuous Integration. Personally, I rely on Travis CI as an automated build system. Regardless of whether an automated build system can be set up and used for a project or not, I prefer to be able to run build steps locally. This prevents stress testing the automated build system and taking away resources from other developers. Also, it gives me more confidence before committing and pushing changes upstream.

[...] For a couple of years now I have been using make, after having been introduced to it when working on a project in 2014. While it has its limitations, it’s short and simple, and most of all, it get’s the job done.

He then talks about the repository he's created to get up and running quickly that creates a simple Makefile to define several make commands and shortcuts for some common tasks. The make it task is the most used, executing all of the other tasks to ensure that all tests pass, the code is well-structured and generates a coverage report to ensure as much of the code is covered by tests as it should be.

Fabien Potencier has a new post to his site covering the addition of support for private repositories to the features Symfony Flex provides.

Many Flex early adopters asked for it. The Symfony Flex server now supports private recipes repositories as announced during my keynote at SymfonyCon Cluj.

Creating a repository for your private recipes is easy. Create a regular Github repository (probably a private one) to store the recipes. The directory structure is the same as for the official Flex recipes repositories. Then, register the repository as a recipes repository. Done.

The private repositories will behave just like the other public ones in your application. You can also use them to override aliases. There are a few differences between public and private, however, like auto-merge not being supported.

The Toptal.com blog has a tutorial posted by Elvira Sheina showing you how to keep a framework project "slim" and manageable in a MVC pattern using a "layered" structure. This structure adds a few extra components to the traditional MVC design to keep functionality cleaner and easier to maintain.

Fat controllers and models: an inevitable problem for most large-scale projects based on MVC frameworks such as Yii and Laravel. The primary thing that fattens controllers and models is the Active Record, a powerful and essential component of such frameworks.

She starts by talking about one of the main issues in MVC applications - "fat" controllers. In this example the controllers contain the bulk of the logic for the application making it difficult to modify and potentially reuse in other places. This is particularly bad when the Active Record pattern is used and the problem of it violating the SRP (Single Responsibility Principle of SOLID development). Instead she promotes the idea of the "layered" design using controllers, a service layer, DTOs, view decorators and a repository layer. She then shows how to implement this kind of structure and tie each of the pieces together with code examples for each piece.

The Master Zend Framework site has continued their series covering Composer and some more advanced concepts than just the usual introduction. In this new tutorial Matthew Setter shows you how to work with forked repositories.

Have you ever submitted a patch to a repository which your application relies on, but, because that patch is vital to the uptime of your application, you can’t wait for it to be reviewed and merged into the next release?

In times like these, it’s fair to want them to move faster than they normally would, so that you don’t have to wait for the normal review, merge, and release cycles. [...] But, you may urgently need the patch to be applied and released. So, what do you do? In times like these, you can use Composer’s ability to use custom repositories, specifically a fork which you create and patch.

If this sounds appealing to you — because perhaps you’re in this very situation right now — let’s now step through the process of modifying your composer.json configuration so that you can use one.

He walks through the Composer configuration you'll need to update to work with the forked repository as you'd expect. He also covers changes that would need to be made for working with private repositories and using local files instead of remote.

Paul Jones has a post to his site with a proposal for a standard structure for PHP packages to help provide consistency across the PHP package ecosystem. His proposal - the Package Development Standards initiative - defines the structure of the repository instead of conventions to be used in the package itself (like naming or object structure).

The new pds/skeleton (and the related research) for public review. If you are a package author, you are invited to post your comments and criticisms of the publication as issues on the relevant Github repository.

The pds/skeleton publication describes a set of standard top-level PHP package directories and files. If you are an author of more than three packages on Packagist, chances are you already follow the standard! That’s because PDS initiative researches the PHP package ecosystem to recognize commonly adopted development practices.

He's putting it out there for public review for now until he can get some feedback from the community on the structure and recommendations made. He also recommends going a head and adding "pds/skeleton" to your "require-dev" section to indicate your compliance to the suggestions he's presented.