Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Laravel News:
New Outer Array Functions Coming to PHP 7.3
Jul 18, 2018 @ 12:47:44

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.

tagged: array outer function php73 feature key value

Link: https://laravel-news.com/outer-array-functions-php-7-3

Laravel News:
Going Deeper with Factories Through Factory States
Apr 11, 2018 @ 10:11:58

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.

tagged: laravel factory state static value model tutorial

Link: https://laravel-news.com/going-deeper-with-factories-through-factory-states

Matthias Noback:
Modelling quantities - an exercise in designing value objects
Mar 29, 2018 @ 11:50:30

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.

tagged: value object model design tutorial quantity

Link: https://matthiasnoback.nl/2018/03/modelling-quanities-an-exercise-in-designing-value-objects/

Websec.io:
Using Canaries for Input Detection and Response
Feb 28, 2018 @ 11:27:51

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.

tagged: canary detect respond value tutorial package pseciocanary

Link: https://websec.io/2018/02/28/Canary-Input-Detect-Response.html

Robert Basic:
Mockery return values based on arguments
Dec 13, 2017 @ 15:13:55

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.

tagged: mockery unittest arguments return value tutorial

Link: https://robertbasic.com/blog/mockery-return-values-based-on-arguments/

Frederick Vanbrabant:
The Broken Windows Theory or "Why Some Projects are Just Destined to Suck"
Jun 20, 2017 @ 09:15:40

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.

tagged: brokenwindows theory software development perceived value opinion

Link: http://frederickvanbrabant.com/2017/06/12/broken-windows-theory.html

Freek Lijten:
Sane defaults over Exceptions
Jan 18, 2017 @ 10:19:13

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.

tagged: sane default value exception error handling defensive programming

Link: http://www.freeklijten.nl/2017/01/04/Sane-defaults-over-Exceptions

PHP Roundtable:
056: Hourly vs Value-Based Pricing
Nov 10, 2016 @ 10:56:50

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).

tagged: phproundtable podcast video ep56 hourly value pricing development work

Link: https://www.phproundtable.com/episode/hourly-vs-value-based-pricing

PHPUgly Podcast:
Episode 24 - The Value of Work
Aug 29, 2016 @ 12:13:20

The PHPUgly podcast has posted their latest episode as recorded on August 18th, 2016 - Episode #24. Join hosts Eric Van Johnson and Tom Rideout as they talk about:

  • The TV show "Mr Robot"
  • the SDPHP and SDLUG Meetups
  • the "FIG Follies" articles
  • the idea of "Being asked to work for free"

You can listen to this latest episode either using the in-page audio player or over on SoundCloud. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates on when the latest shows are released.

tagged: phpugly podcast ep24 value work ericvanjohnson tomrideout

Link: https://soundcloud.com/phpugly/episode24

QaFoo.com:
Never Use null
May 03, 2016 @ 13:07:32

On the QaFoo.com blog they've made a recommendation in their latest post - they suggest that you never use null.

When doing code reviews together with our customers we see a pattern regularly which I consider problematic in multiple regards – the usage of null as a valid property or return value. We can do better than this.

Let's go into common use cases first and then discuss how we can improve the code to make it more resilient against errors and make it simpler to use. Most issues highlighted are especially problematic when others are using your source code. As long as you are the only user (which hopefully is not the case) those patterns might be fine.

They talk about some of the most common uses they see for using null in PHP applications including setters for class properties (injection). They point out that in PHP 7 a missing value on a property would result in a Fatal error and make the functionality harder to test overall. They suggest that all required dependencies be injected on object construction instead, making it easier to know the current state of the object on testing. They also talk some about using null as a return value, how it could make debugging difficult and a solution that could make more sense - throwing an exception instead.

tagged: never use null return value injection setter solution suggestion debugging

Link: https://qafoo.com/blog/083_never_use_null.html