Michael Dyrynda has a post to his site sharing a method he's worked up for customizing the URL signing key that the Laravel framework uses to sign URLs to ensure the integrity of the URL's contents.

Since 5.6, Laravel has shipped with functionality to sign URLs. These URLs append a "signature" to the query string, so that Laravel can verify that the link has not been tampered with since it was created. This also allows you to generate temporary signed routes that expire after a configured period of time.

This is useful for things like verifying account emails, or enabling passwordless logins.

Passwordless logins is something that is quite useful for an application, but what if you wanted to be able to generate a signed URL in one application that would allow you to log in to a second application?

He starts by defining the use case, requiring multiple signing keys to be used, one for customer URLs and another for admin URLs accessing the same content. He makes this work through the use of a custom key resolver, pulling the key for the signing dynamically. He also shows how to update the passthrough authentication handling, allowing the administrators (staff) of the system to bypass normal authentication handling and more directly view the user's information.

On TheCodingMachine.io there's a tutorial posted by David Négrier covering an interesting idea when handling "falseness" in your PHP application - throwing exceptions rather than returning false. In this case, he introduces the "safe" library to help make this easier.

At TheCodingMachine, we are huge fans of PHPStan. PHPStan is an open-source static analysis tool for your PHP code. [...] PHPStan has this notion of "levels" and we strive on each of our projects to reach "level 7" (the maximum level). But PHPStan is constantly improving, and reaching level 7 becomes harder and harder as the tool becomes more strict (this is a good thing!).

The post includes an example of this increasing strictness, showing how a more recent check looks at a file_get_contents call and ensures all possible return values are evaluated (it returns false when it errors). They refactor the code example to more correctly check for this, but losing some of the "expressiveness". The tutorial then spends some time talking about the history of PHP and why things return false rather than throw exceptions on error. It covers some of the basics of how the safe library works and a PHPStan extension that can help find places that need to be wrapped by "safe" to throw exceptions when false is returned.

On the Laravel News site they've shown a spotlight on a new feature that's coming with the next major release of the PHP language (v7.3): outer array functions.

PHP 7.3 introduces two new array functions for working with the “outer” keys of an array. The RFC proposal included four new functions for both keys and values, but only the array key functions were accepted: array_key_first() and array_key_last().

[...] Although the outer array value functions were declined, at least new functions will be available for getting the outer keys of an array.

They then provide some code examples of this new functionality, showing how use these new functions to extract values. It also includes examples of the two functions - array_value_first and array_value_last - that were rejected from the RFC when voting happened.

The Laravel News site has posted a tutorial that takes you deeper with factories when using the framework looking at the factory states.

I suspect that if you are familiar with Laravel that you might use factories and possibly even factory states in your application development. The documentation shows you the mechanics of using factories to seed and create test data, but there are a couple of guiding thoughts to using factories with your models effectively that I’d like to consider.

He starts with two options he sees for using factory states: making them with static values or using them to make simple models instead. He goes through these two options, introducing some of the basic concepts of each, how it would work and the code to make it happen. He also covers a few other approaches including the use of a trait to include the factory functionality directly in a class. He finishes the post with a few links to more information in the Laravel manual and other outside resources/tools.

Matthias Noback has a new post on his site with his thoughts about the design of value objects. He makes use of an example he recently saw in the code he was working with: the idea of "quantities" of items.

I recently came across two interesting methods that were part of a bigger class that I had to redesign. [...] What happens [in the methods] is: we have an order line, which keeps track how much of a certain product has been "ordered", and then how much of it has been "delivered" so far. It also keeps track of how much is currently still "open". Changes to these "delivered" and "open" quantities happens when we "process" a delivery, or "undo" a delivery.

I was reminded of a recent blog post by Nicolò Pignatelli where he quoted a question from another programming website. Adopted to the situation at hand: "Which variable type would you use for representing a quantity? Integer, Float or String" It's a trick question, because all the answers are wrong. Nicolò advises not to use a primitive type value, but to design a value object that can represent a quantity.

He then walks through the process for refactoring this quantity handling out into a value object replacing the current float handling. He recommends applying more thought to how the object will be used and how the different types (open, ordered and delivered) relate to each other. He also includes examples of how to replace the add/subtract operations in the original code while still using value objects as immutable constructs.

The Websec.io site has posted a new tutorial today showing how to use "canary" values and the psecio/canary PHP package to detect and respond to potentially malicious input.

I'm sure you've heard the common phrase "a canary in a coal mine" when people talk about safety and detection of issues. When miners used to go down to work, there was a danger of trapped gasses being released as they were digging. Some of these gasses were hard for humans to detect and, if enough was breathed in, could lead to illness or even death. In order to help the miners detect and avoid these kinds of issues, they would take a canary (the bird) down into the mine with them.

[...] The idea of a "canary" value in the security world is pretty similar. A "canary" value is one that - real or faked - is somehow exposed outside of your own system. If this value is used you need to be notified immediately so you can take action and gather more information about the usage and any other associated issues.

The tutorial then introduces the psecio/canary package and shows some of its basic use detecting input and setting up notifications. It also covers some of the package's integrations for notifications with services like Slack, PagerDuty and custom Monolog handling. It also provides an example of it in a more "real world" situation of a Slim framework middleware that detects incoming GET parameters.

Robert Basic has a new post to his site where he shows how to use the Mockery unit testing too to return different values for different arguments. Fortunately there's something already built into the tool to help handle this.

Sometimes when working with Mockery mock objects, we want to tell a mocked method to return different values for different arguments. It is a rare occasion when I need this feature, but every time I need it, I’m happy it’s there.

The feature that allows us to return different values based on arguments is the andReturnUsing Mockery method, which takes a closure as an argument.

He includes examples of the use of this andReturnUsing method in mocks and showing that there's more than one way to accomplish the same kind of goal. While this is a useful method to use when needed he points out that refactoring the code under test is probably a better way to go instead.

Frederick Vanbrabant has posted an interesting article to his site covering the "broken windows" theory, what it is and how it shows that some projects are just destined to suck.

Why is it that most legacy software projects are not really fun to work on? How can we stop that greenfield project to turn into one of those dull big projects? I would argue that it’s all in the foundation.

He starts with a brief description of the "broken windows" theory based on the 1982 definition proposed by James Q. Wilson and George L. Kellin. Basically it states that all it takes is one "broken window" to change the perceived value of something, even if it's a small thing. He then gets down to the code level and relates it back to some examples from the Slim framework project. In his examples he shows how it might look after a refactor and how removing best practices makes it harder to understand (breaking windows). To help prevent it, he recommends following the Boy Scout rule of leaving the code better than you found it and using automation to help find and fix the issues.

In a new post to his site Free Litjen talks about defensive programming and the part that sane default handling plays when dealing with exceptions that might pop up.

With over half a million visitors a week and lots of scrapers, bots and other stuff visiting, these exceptions and fatal errors clog up logging quite a bit. Not to the point that we can't handle the volume, but it generates false positives in monitoring channels and it is something we do not want to act upon anyway.

So while I'm happy to see some defensive programming I would be even happier if exceptional situations would be silently resolved to default situations.

The post starts with a quote about defensive programming and how, despite it not being an ideal use, many applications had been seen using exceptions to handle errors and messaging. He proposes another methodology where a set of default values are used instead of just failing on any error hit with the input. The idea has merit but it can also lead to other frustrations like hidden errors in testing and situations where an exception makes more sense than a default.

The PHP Roundtable podcast, hosted by Sammy Powers, has posted its latest episode. In this new show he's joined by Keith Casey, Tim Lytle and Mike McDerment to talk about hourly versus value based pricing when charging for freelance development work.

There are two seemingly contradicting philosophies about how to charge clients for programming work. The hourly camp suggests that the client is paying for your skill and hiring you for your time. The value-based pricing camp suggests that the programmer should price a project based on its value to the client instead of the hours it will take to build it. Today we chat about these two ideas and discuss the pros and cons of both.

You can catch this latest episode either using the in-page audio or video player or by watching the live recording directly over on YouTube. If you enjoy the show and want to see more like it, be sure to subscribe to their feed and follow them on Twitter for information about the most recent and upcoming shows (and live recordings).