larry@garfieldtech.comI made a TYPO (5.5.2021, 21:55 UTC)

I made a TYPO

Submitted by Larry on 5 May 2021 - 4:55pm

I am a firm believer in "anything worth doing is worth doing right." So when given the opportunity to get paid to do that, it's hard for me to say no. Which is why I didn't.

I am happy to report that this is my first week in my new role as Staff Engineer on the TYPO3 core contributors team.

Continue reading on PeakD.

Christian WeiskeLaravel: Marking notification e-mails as automatically submitted (2.5.2021, 18:55 UTC)

Process mails from web applications like e-mail address verification and password reset mails should be tagged as "automatically submitted" so that mail servers do not respond with "Out of office" or vacation notification mails.

The official standard for that is RFC 3834: Recommendations for Automatic Responses to Electronic Mail, which defines an e-mail header Auto-Submitted: auto-generated for our use case.

Laravel notifications

E-mails automatically built from Laravel notifications can be modified to contain that header: Inside the toMail() method, register a modification callback for the MailMessage class:

namespace App\Notifications;

class ResetPassword extends \Illuminate\Notifications\Notification
     * Build the mail representation of the notification.
     * @param  mixed  $notifiable
     * @return MailMessage
    public function toMail($notifiable)
        return (new \Illuminate\Notifications\Messages\MailMessage)
            ->withSwiftMessage([$this, 'addCustomHeaders'])
            ->subject(_('Reset your password'));

     * Add our own headers to the e-mail
    public function addCustomHeaders(\Swift_Message $message)
        $message->getHeaders()->addTextHeader('Auto-Submitted', 'auto-generated');
Derick RethansPHP Internals News: Episode 83: Deprecate implicit non-integer-compatible float to int conversions (29.4.2021, 08:11 UTC)

PHP Internals News: Episode 83: Deprecate implicit non-integer-compatible float to int conversions

In this episode of "PHP Internals News" I talk with George Peter Banyard (Website, Twitter, GitHub, GitLab) about the "Deprecate implicit non-integer-compatible float to int conversions" RFC that he has proposed.

The RSS feed for this podcast is, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:14

Hi, I'm Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 83. Today I'm talking with George Peter Banyard, about another tidying up RFC, George, would you please introduce yourself?

George Peter Banyard 0:31

Hello, my name is George and I work on PHP in my free time.

Derick Rethans 0:35

Excellent. I was just talking to Larry Garfield, and he was wondering whether you or himself, are the second often guests on this podcast, but I haven't run a stats. But it's good to have you on again. Following on for from other numeric RFCs, so to speak. This one is titled deprecate implicit non integer compatible floats to int conversions. That is a lovely small title you have come up with.

George Peter Banyard 1:01

Yeah, not the best title.

Derick Rethans 1:03

What is the problem that this RFC is trying to solve, or rather, what's the change that is in this RFC is trying to solve?

George Peter Banyard 1:11

Currently in PHP, which is a dynamic language, types are not known at the statically at compile time, so it's so everything's mostly runtime. And most type conversions are relatively sane now in PHP 8, because like numeric strings have been kind of fixed. But one last standing issue is that floats will pass an integer check, without any notices or warnings. Although floats, don't usually fit in integer will have like extra data which can't be represented as an integer. For example, they can have a fractional part, or they can be infinity, or not a number if you divide, like infinity by infinity, or 0 over 0 or other things like that.

Derick Rethans 1:55

These are specific features of floating point numbers on computers?

George Peter Banyard 1:59


Derick Rethans 2:00

Is there any prior work that is RFC is building on top of

George Peter Banyard 2:03

It builds up on top on the saner numeric string RFC, because it tries to like make the whole numericness of PHP, as a concept better and like less error prone, but in essence it's mostly self contained. If you use a floating point number, were you should be using an integer. If the floating point number, is considered an integer because it only has like decimal zeros, and it fits in the integer range, then you'll have like no error. So if you use 15.0 as an array key, it gets converted to 15, you'll get don't get any error because it's like well it's just 15 like it doesn't mind. But if you do 15.5, then you'll get like a, like a deprecation notice which will tell you it's like, well, here's the key gets implicitly converted, you should be aware of this because if you use 15 somewhere else, you'd be overriding the value.

Derick Rethans 2:54

Truncated by Planet PHP, read more at the original (another 16989 bytes)

Liip Inside our onboarding program or how we welcome new Liipers (28.4.2021, 22:00 UTC)

Starting at a new company is a huge challenge. We feel you – been there, done that! ;-) That is why we have an onboarding program in place, which makes you feel part of the Liip family from day 1, hopefully. Your recruitment process was a success, let's make your onboarding great too. So let’s jump right in!

Meet your onboarding buddy

Céline, Hendrik, Janina, Stefan... these are four of the almost twenty onboarding buddies at Liip spread over all the six locations. And you will get a buddy too! Your onboarding buddy is your go-to person, your sparring partner for social and cultural aspects at Liip.

They are usually based in the office you are joining, while not part of your work team. Additionally, you get a work buddy for work-related topics who tell you all about the projects you will work on. Responsibility and autonomy are key at Liip. We will support you to find your way and embrace our values.

Your buddies will guide you through the onboarding program. Providing you with an overview of the company, our processes and tools. Together, you will define your trial period goals and regularly meet to reflect and share impressions and feedback.

Last but not least, social gatherings! They are part of the #liipway, and your onboarding buddy aims for making you feel welcome at the (online) apéro, game session or yoga class – if you wish to take part. We are striving for a successful and pleasant integration to Liip for you.

At the end of your three-month trial period, you will be invited to the so-called “trial period meeting”. This is a dedicated time to identify what has been moving you forward, what has been holding you back and what opportunities and challenges might arise. You will self-reflect and get feedback from peers as well as your onboarding buddy. In other words, this is our ritual to finalize the onboarding process and confirm your hiring.

Go with the flow

Everything is organized so that you can “just” surf the wave. Technically speaking, you will get what you need to work, such as a brand-new laptop, an ergonomic desk and chair, a monitor, a keyboard, a mouse, etc. All of it is organized on-site or sent to your place (maybe not the desk nor the chair ;-) ) in case you start your onboarding program remotely.

Thanks to a clear and easy to follow checklist (aka your onboarding kanban board), you have an overview of your progress within the onboarding program at any time. Where to get support, how to contribute to the external communication of Liip, how our salary system works, and so much more will be taught to you.

Trainings are part of the program too. Holacracy, Agility and Feedback trainings are on the menu. And you will learn more about your personal education budget.

Take part in the #liipway

All you need is curiosity and enthusiasm. Let yourself be guided, and enjoy the ride! We can only advise you to participate in social and health activities to get a taste of the #liipway, either on-site (as soon as this will be possible again) or online like coffee breaks, game sessions, yoga or boot camp courses, ...and apéros! Our tool meet-a-liiper-with-donut makes meeting new work colleagues from all over Liip, even during remote times, a walk in the park.

Don’t be shy and dare to ask questions (all of them!). How you experience the onboarding program has the utmost importance to us. Please give us your honest feedback, so that we keep on improving it.

Sergey MitroshinPHP 8.1: `never` Return Type is Dangerous (23.4.2021, 02:59 UTC)

There are many features already introduced in PHP 8.1, and among them the new never return type:

function doSomething(): never {
    // do something

The idea is pretty straightforward: if the execution flow is never supposed to leave the function, it should be marked as never. If the execution flow somehow reaches the end of the function, PHP will throw an error.

Although it seems to me like a good idea, there's a hidden catch we need to be cautious about.

Continue reading
Liip Prototyping a strategy (22.4.2021, 22:00 UTC)

Content Strategies are not typically tested with users

And we didn’t plan to do so in the beginning. The project started relatively conventional. My colleague Caroline Pieracci was asked to do the Content Strategy for a Swiss retailer and invited me to join the team. As a UX Designer I was asked to lead the stakeholder interviews for the client.
The first workshop was dedicated to get insights about the strategy of the client, their business goals and customer needs. To understand how we can help reach these goals with content, we are proposing a core message. Of course the main topics the client wants to talk about and what users are interested in was part of that too.

But why stakeholder interviews?

I mostly do stakeholder interviews at the very beginning of the project, to understand their goals, needs and pain points. It seemed a bit late in the process for me. When asked this question, the client explained that they wanted to inform the stakeholders, get their feedback, understand if the content strategy was valuable for them and get their buy in. During the reflection with Caroline about everything we heard from the client, I felt that what they actually wanted was to communicate and to test their Content Strategy.

A prototype to communicate important aspects of your project

Prototypes serve various purposes. Either to explore different solutions and opportunities, or to evaluate a solution, reduce the number of options and decide what to focus on. Or to communicate important aspects of your project. A communicative prototype can ignite meaningful discussions with your stakeholders and reduce friction and misunderstandings right from the start. It can be a valuable strategic tool to present, convince and inspire your management or stakeholders. That is why our client was all in and the prototyping began.

We used a PowerPoint presentation as a prototype #nokidding

Caroline had a poster in mind as the final delivery. A nicely designed visualisation of the core messages for the team to hang up in their office. In the end, our prototype was a PowerPoint presentation as this is the main medium for communication used by our stakeholders. It explained each part of the strategy and how it was created. The presentation was not polished at all, neither designed, and it had some blanks and question marks in it. We even put a “draft” sticker on each slide to make sure that the presentation was not judged by its bad looks.

Five interviews in one day

The testing was done remotely, all in one day and with the whole project team present. From the stakeholder map that we prepared in the kick-off meeting, our client picked the five most important people they wanted to talk to. We had 10 min to present the prototype and 20 min to ask our questions.

  • After seeing our content strategy prototype, what questions do you have? What is unclear for you?
  • What is your first impression of the content strategy, what goes through your mind?
  • What is still missing in our content strategy?
  • What is superfluous?
  • What opportunities do you see when we implement this content strategy?
  • What risks do you see?
  • What does it take to make this content strategy a success?
  • Is there anything else you would like to say on the subject?
    The whole project team took notes. After each interview all the details were collected on our Miroboard. This took about 20-25 min and after a short break the next interview took place. The technique and the questions are coming from Jake Knapps book Sprint and felt great to be used in the context.

    Confidence to release the Content Strategy

    The feedback was very positive and gave the client a great boost and a lot of confidence to be on track. The stakeholders were pleased to see the Content Strategy in an early stage. Their feedback also pointed out a couple of things that were missing or not clear enough.
    The next day we met again and put all the feedback from the interviews on a huge “pile” on the Miroboard and prioritized them to decide what we will implement for the first release of the Content Strategy. We used the MoSCoW method and organised them into “must have’s”,”should have’s” and “won't have’s”.

    Continuous adaptation

    The team that would mainly work with the Content Strategy on a daily basis, was invited to give their feedback on the prototype too. We are planning to invite them again, after they have worked with the Content Strategy for a while, to understand what works well for them and what doesn’t. It is a living document that needs to be adjusted and improved regularly.

    Reduce risk and uncertainty

    Experimentation, prototyping and testing is not always easy, but this project went down really smooth, and the collaboration with the client was great. The only c

Truncated by Planet PHP, read more at the original (another 683 bytes)

Derick RethansPHP Internals News: Episode 82: Auto-Capturing Multi-Statement Closures (22.4.2021, 08:10 UTC)

PHP Internals News: Episode 82: Auto-Capturing Multi-Statement Closures

In this episode of "PHP Internals News" I chat with Larry Garfield (Twitter) and Nuno Maduro (Twitter, GitHub, Blog) about the "Auto-Capturing Multi-Statement Closures" RFC.

The RSS feed for this podcast is, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:14

Hi, I'm Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 82. Today I'm talking with Nuno Maduro and Larry Garfield. Nuno, would you please introduce yourself?

Nuno Maduro 0:30

Hi PHP developers. My name is Nuno Maduro, and I am software engineer at Laravel, the company that owns the Laravel framework, and I have created multiple open source projects for the PHP community, such as Pest PHP, Laravel zero, collusion and more.

Derick Rethans 0:48

Alright, and Larry, could you please follow up on that.

Larry Garfield 0:51

Hello world, so I'm Larry Garfield. You may know me from several past podcasts here, various work in the PHP fig, and all around gadfly and nudge of the PHP community.

Derick Rethans 1:03

Good to have you again Larry and good to have you here today, Nuno. The RFC, that we're talking about here today is to do with closures, and the title of the RFC is auto capturing multi statement closures, which is quite a mouthful. Can one of you explain what this RFC is about?

Nuno Maduro 1:20

As you said, the RFC title is indeed auto capturing multi statement closures. But to make it simple, we are really talking about adding multi line support to the one line arrow functions that got introduced it, in PHP 7.4. Now, this new multi line arrow functions have exactly the same features as the one line arrow functions, so they are anonymous, locally available functions; variables are auto captured lexically meaning that you don't actually need the use keyword to manually import the use of variables, they just get auto captured from the outer scope. And the only difference really is one line arrow functions have a body with a single expression. This RFC actually allows you to use a full statement list that possibly ends with a return.

Derick Rethans 2:18

Excellent, what the syntax that you're proposing here?

Nuno Maduro 2:22

Well, as you may know, one line arrow functions have the syntax, which is fn, parameter list, and then that arrow expression thing, and this new RFC proposes that, optionally, developers can pass a curly brackets with statements, instead of having that arrow expression syntax. Now, this curly brackets with statements, simply denotes a statement list that potentially ends with a return. Concerning the Auto Capture syntax, we will be just reusing the Auto Capture syntax and feature that already exists on one line arrow functions, meaning that you don't need the use keyword to manually import variables. And of course, the syntax itself, in the in the feature, works the exactly same way. Concerning the syntax, it's also important to mention that this RFC was done in combination with the short functions RFC from Larry, but I think I'm going to let Larry speak about that later on this episode.

Derick Rethans 3:26

What's the main idea behind wanting to introduce this auto capture m

Truncated by Planet PHP, read more at the original (another 20326 bytes)

Liip Code reviews: Dos, Don'ts and a How-to (20.4.2021, 22:00 UTC)

Answer: It's complicated. As always. But bear with me!

A few words about code reviews

From my point of view, code reviews should be an integral part of agile software development. There's an IEEE standard for code reviews that defines all kinds of reviews, but I won't go into much details here.

For me, the main goal of code reviews should be to improve collaboration within a development team and to improve the quality of the product. Each and every review should be seen as a learning opportunity for both the person reviewing and the author of the change.

Our approach to improvement

It's generally a good idea to know and analyze the status quo before implementing any change. And what's better to measure how code reviews are done than doing actual code reviews? No sooner said than done!

So we created a repository with a small application. Nothing too fancy, a simple calculator for the CLI written in Python, no libraries, no frameworks. Next, we created a bunch of merge requests and let all the devs review them in pairs in a workshop. We gave them around 30 minutes to review the code as they usually would.

And then came the fun part:

Reviewing the reviews

Each team explained how they did the code review, what they focussed on and what kind of problems they found. The results were rather interesting: There was a set of problems every team found, but also some issues that were unique per team.

And there's a good reason behind that: The approaches were vastly different. One or two teams started by cloning the repo and checked if they could get it running. Others started to analyze the code to find places it could crash. Yet another team read the documentation and the tests first, checking if it was up to date.

They were all doing a code review and they were all doing it very differently. There's nothing wrong with that. Every approach is good and has it's advantages, as long as it's not the only thing that's looked at.

The goal of this workshop was not only to analyze how code reviews were done so far. We also wanted to establish a common understanding of how code should be reviewed and why: A set of best practices and guide lines. We also added some well-established guidelines into the mix.

Some of our Dos and Don'ts

This is a structured, boiled down version of the best practies and guidelines we established during the workshop.

A review has three phases: Preparation, the actual review and post-processing. There's two parties involved: The author and the reviewer.

In general, for everyone

  • Every change is an opportunity to do a review
  • Avoid reviewing too much code at once. Going beyond 200-400 LOC per hour might have a negative impact on the quality of the reviews
  • Don’t assume malice
  • Strive to create learning opportunities for both the author and the reviewer
  • Be kind
  • Let different people review your code
  • Review code of others on a regular basis
  • Seniors are encouraged to let juniors review their code, too
  • Juniors are encouraged to ask to perform reviews
  • Code style and conventions can be checked automatically: Consider introducing automated sniffs/checks to eliminate any inconsistencies beforehand

Before a review, for the author

These are some steps that can be taken in order to prepare the code for the review. They aim to streamline the process and catch some points upfront.

  • Review the code yourself
  • Ask for a review proactively
  • For larger or more fundamental changes, several people may be asked to do reviews. They can do a review together or independently. This has the added benefit of more people knowing about a change and might induce further discussion about the architecture
  • Make sure it’s understood what your code tries to achieve
  • Add a comment to the ticket for handover with
  • If a solution is complex: Explain why, ideally directly in the code
  • Comments on the change can also be added by the author before a review happens. Those can be used to explain things where comments in the code are not possible (JSON files etc.)
  • Alternatively, do pair programming or even group programming

During the review, for the reviewer

These tips aim to optimize the quality of the review and its results. They also make sure that the review is exhaustive by covering for edge cases, checking documentation, trying different approaches in your head and identify oppourtunities.

  • Don’t neglect positive feedback: If something is well-structured, especially elegant etc., point these things out, too

Truncated by Planet PHP, read more at the original (another 2106 bytes)

Voices of the ElePHPantInterview with Chris Pitt (19.4.2021, 02:36 UTC)
Derick RethansPHP Internals News: Episode 81: noreturn type (15.4.2021, 08:09 UTC)

PHP Internals News: Episode 81: noreturn type

In this episode of "PHP Internals News" I chat with Matthew Brown (Twitter) and Ondřej Mirtes (Twitter) about the "noreturn type" RFC.

The RSS feed for this podcast is, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:15

Hi I'm Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 81. Today I'm talking with Matt Brown, the author of Psalm and Ondřej Mirtes, the author of PHPStan, about an RFC that I propose to alter the noreturn type. Matt, would you please introduce yourself?

Matthew Brown 0:37

Hi, I'm Matthew Brown, Matt, I live in New York, I'm from the UK. I work at a company called Vimeo, and I've been working with for the past six years on a static analysis tool called Psalm, which is my primary entry into the PHP world, and I, along with Ondřej authored this noreturn RFC.

Derick Rethans 1:01

Alright Ondřej, would you please introduce yourself too?

Ondřej Mirtes 1:04

Okay, I'm Ondřej Mirtes, and I'm from the Czech Republic, and I currently live in Prague or on the suburbs of Prague, and I've been developing software in PHP for about 15 years now. I've also been speaking at international conferences for the past five years before the world was still alright. In 2016, I released PHPStan, open source static analyser focused on finding bugs in PHP code basis. And somehow, I found a way to make a living doing that so now I'm full time open source developer, and also father to two little boys.

Derick Rethans 1:35

Glad to have you both here. We're talking about something that clearly is going to play together with static analysers. Hence, I found this quite interesting to see to have two competitive projects, or are the competitive, or are the cooperative.

Matthew Brown 1:56

I think half and half.

Derick Rethans 1:57

Half and half. Okay.

Ondřej Mirtes 1:59

Competition is a weird concept in open source where everything is released for free here that

Derick Rethans 2:04

That's certainly true, but you said you're making your living out of it now so maybe there was something going on that I'm not aware of. In any case, we should probably chat about the RFC itself. What's the reason why you're wanting to add to the noreturn type?

Ondřej Mirtes 2:18

I'm going to start with a little bit of a detour, because in recent PHP development, it has been a trend to add the abilities to express various types natively, in in the language syntax. These types, always originally appeared in PHP docs for documentation reasons, IDE auto completion, and later were also used, and were being related with static analysis tools. This trend of moving PHP doc types tonight this type started probably with PHP seven that added scalar type hint. PHP 7.1 added void, and nullable type hints, 7.2 added object type, 7.4 added typed properties. And finally, PHP, 8.0 added union types. Right now to PHP community, most likely waits for someone to implement the generics and intersection types, which are also widely adopted in PHP docs, but there's also a noreturn, a little bit more subtle concept, that would also benefit from being in the language. It marks functions and methods that always throw an exception, or always exit, or ent

Truncated by Planet PHP, read more at the original (another 20092 bytes)

LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP