On the Script-Tutorials.com site they've posted a lengthy tutorial that covers many common design patterns - 23 of them - and how they could be implemented in PHP.

Today we are going to talk about design patterns in web development, more precisely – in PHP. Experienced developers are probably familiar with this, but this article will be extremely useful for all novice developers. So, what is it – design patterns? Design Patterns aren’t analysis patterns, they are not descriptions of common structures like linked lists, nor are they particular application or framework designs. In fact, design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” In other words, Design patterns provide a generic reusable solution to the programming problems that we encounter every day.

[...] Design patterns not only make software development faster, but also encapsulate big ideas in a simpler way. Also, be careful not to use them in wrong places in order to avoid unpleasant situations. In addition to the theory, we also give you the most abstract and simple examples of design patterns.

The tutorial starts with a table listing out the category (purpose) of the pattern, the design pattern name and some of the aspects of it that could vary depending on interpretation. The article then goes through each of the 23 patterns and includes the code to implement them. There's not much in the way of description about each but there are one or two sentences about its primary use.

The Pehapkari.cz blog has continued their series covering domain-driven design with their latest post. In this new article they focus on the implementation of the concepts they've been covering starting with the domain model.

It is great to model something and now we have reached the point where we turn the model into the code. We will implement the model, no persistence, no input, only the most important part - the domain model. The implementation will be supported by tests and we will see how easy it is to test domain objects. We will also discuss the connection to the ubiquitous language and model and practical aspect of object encapsulation.

The tutorial then starts in covering the domain model structure and includes a few things to to think about during the implementation. It talks about reading values from the object and links to the full code on GitHub (rather than fill up the post with code). The post finishes by covering testing of the model, the idea of test-driven development and how it fits in with domain-driven design.

Robert Basic has a post to his site covering interfaces and their use in PHP, including what to consider when creating effective interfaces.

Creating and implementing interfaces in our code is important. It helps with swapping out components, eases testing, separates the what from the how.

But, it’s not enough just to slap an interface on a class and be done with it. We also need to consider on what are we putting that interface on.

He starts with an example of a feed (RSS) reader where an interface defines a queue handler with an add method. Eventually he makes some decisions and implements the queue in a concrete class but points out that there's something "fishy" about the example. He covers the three issues he sees including the class doing two things and how it locks the functionality into the queue. He refactors the example, abstracting things out to more correctly adhere to the Single Responsibility Principle and split out the database handling from the queue functionality.

On the SitePoint PHP blog they've posted a tutorial from author Francesco Malatesta covering his Laravel package building workflow.

Packages are a really important part of the Laravel experience (just like with any other framework). Whatever we need to do, there’s probably already a package for it out there; ready for a composer require to bring some magic in.

Some weeks ago, I had an idea for a new one. I work for AdEspresso, where we have a Symfony FeatureBundle, which handles feature toggling in our projects. It’s a really nice piece of code that we use to release new features only for specific subsets of users. So, I asked myself… why not port it for Laravel? That’s how my Laravel Feature package idea was born.

[...] In this article, I will try to explain how I prepared my development environment for it, and which choices I made when building the package. Not the development of every line of code per-se, but the actual workflow of getting from nothing to a full package.

He starts by talking about a handy addition to an application that can make the rollout of your new package easier: feature flags. He then starts in talking about the Composer configuration of the package and its "skeleton" (default directory and file structure). The tutorial then starts in on the code in the package itself covering the abstraction of domain code and implementing the features including the configuration, Blade template and the matching facade.

The Codeception blog has recent post they've written up talking about writing better tests for your application and the difference between expectation and implementation as it relates back to meaningful tests.

What makes a meaningful test? This question should always be asked. No matter we write your tests first or tests after, they may stay in a project for years and it is pretty important them to test the things that really matters. Badly written tests can slow us down by constantly failing on each implementation change, and such tests can be written no matter you follow TDD or not. The idea of a test is to ensure that software works and not to freeze it at specific point.

Such situation happens when a test is bound to implementation details. [...] But how to understand what is stable and what is not? We need to use interfaces. Not that one which is written as interface keyword in PHP but a general term: User Interface, API. And that’s what makes unit testing and browser testing similar: we always need to rely on public interfaces for a test.

They give an example of a test that's "bound to implementation details" from the Magento codebase that relies on a specific function implementation (the "makdir" method). This function is a part of the Symfony functionality, not Magento, and what might happen if things change in your application. They note that the main difference is testing for the result versus testing for the behavior of the functionality. The tutorial wraps up by suggesting that the only testing that should be done is on public, well-defined interfaces that are not as subject to change and not copying logic into tests.

Rob Allen has a post to his site announcing the latest release of the Slim Framework - v3.4.0 - and an update that allows for full PSR-7 support, telling Composer that the framework fully supports it now as well.

I've been neglecting Slim's PR queue recently, so this weekend I dedicated a lot of time to merging all the good work that our contributors have done. As a result, I'm delighted to release version 3.4.0! This release has a larger set of changes in it than I would have ideally liked which is a direct consequence of having gone two months between releases rather than one.

One particularly interesting addition that we have a made this release is adding a provide section to our composer.json file. [...] This means that we have informed Composer that Slim provides a valid implementation of the interfaces in psr/http-message-implementation virtual package that defines the PSR-7 interfaces.

This basically means that if you're using other libraries/tools that require a PSR-7 compatible system to work correctly, they'll detect that Slim fully supports it.

On the Symfony Finland blog they have a recent entry looking at some of the other alternative PHP implementations with a brief overview of each.

In the past there have been alternative environment for running PHP in PIPP for Parrot VM and Quercus for JVM, but none of these have had real staying power. This changed with HHVM from Facebook in the early 2010's. It's completely separate from the Zend PHP implementation and is a fully featured alternative.

[...] Many the implementations are just proof of concept implementations and are far from supporting all the language features and rendering them to be useless for running Symfony or other contemporary applications. Regardless of whether these are immediately useful for projects it's interesting to follow these efforts.

The four covered in the post allow for PHP to be run in some pretty non-traditional environments:

• HippyVM letting PHP run in Python (PyPy)
• JPHP that runs PHP in Java
• Tauga VM using Rust to let PHP run compiled via LLVM
• Peachpie for running PHP on .NET

There's a brief look at each of these projects included and, while most aren't close to what HHVM has to offer, you might take a look and see if they could be interesting to try out in some of your development.

The SitePoint PHP blog has a new tutorial posted (a repost from this article used with permission) about implementing a new operator in the PHP core language: a "range" operator. This operator allows the definition of a range of values (integer/float) as an internal PHP representation.

In the post below, Thomas Punt implements the range operator in PHP. If you’ve ever been interested in PHP internals and adding features to your favorite programming language, now’s the time to learn! This article will demonstrate how to implement a new operator in PHP. The following steps will be taken to do this: updating the lexer, updating the parser, updating the compilation stage and updating the Zend VM. This article therefore seeks to provide a brief overview of a number of PHP’s internal aspects.

He starts with a look at the range operator and how the intended functionality would work (including when the errors would be thrown). He then goes through the steps listed above and makes additions to the source, complete with the C code to make each change. The article is not only a good look at how to add a custom operator but also gives a good overview of the internals of PHP and how things fit together.

In his latest post to his site Alejandro Celaya shares some suggestions about how to make a good, safe persistent login feature for your application. This is usually referred to as the "remember me" handling and is widely used to help improve the overall user experience.

I'm sure you are familiar with those "remember me" checkboxes in login forms. They are a common way to allow a user to keep his/her session in a web application for an extended period of time when he is in a trusted computer.

One could think that it is a small and easy-to-implement feature, but it has indeed a lot of considerations. [...] In this article I’m not going to show you how to implement a persistent login in one or another programming language, but what are the good practices that should be followed when you implement it in the way you want.

He starts off with some thoughts about the wrong way to handle the persistent login (like just making a long-life cookie) and what some of the consequences could be. Instead he suggests using a cookie (with a random generated token) that's long running, maybe 2 weeks. The difference here is that this token is then refreshed once the token is validated and reset. This reduces the risk of an older token being used on another source too. He also shares some other security concerns to think about in this setup including the use of one-time tokens, potential multiple persistent sessions and when it might be good to re-prompt for the password.

Evert Pot has shared some of his thoughts about why he has a problem with password_hash (and friends). His thoughts are initially about this particular feature but they're actually wider than that.

The initial introduction and rfc for these functions made me uneasy, and I felt like a lone voice against many in that I thought something bad was happening. I felt that they should not be added to the PHP engine. I think that we should not extend the PHP engine, when it's possible to write the same API in userland, or there are significant benefits to do it in PHP, such as performance. Since the heavy lifting of the password functions is done by underlying libraries that are already exposed to userland-PHP, it didn't make sense to me to expose it as well in the core.

He includes a list of things he sees as drawbacks for new C-based functionality in PHP including the fact that it extends the "PHP specification" and forces other projects to implement it (like HHVM). He does include a few positives, though, such as the increased visibility and legitimacy, but still thinks they don't outweigh the negatives.