Introduction

As a PHP web developer, it's almost inevitable that you'll come across closures and arrow functions at some point. They are both handy features that can be used to write pretty powerful code when used correctly.
But I'll admit, when I first started learning PHP (and to code, in general), I didn't have much of an idea of what closures were. I knew they were a thing, but I didn't really understand how they worked, when to use them, or what they achieved.
So in this blog post, I'm going to cover the basics of closures and arrow functions in PHP. We'll discuss what each of them does, where you might want to use them, and then we'll explore the differences between them.

Closures in PHP

Closures are anonymous functions that can be stored in variables, passed as arguments to other functions, or returned as values from other functions.
For any of my Laravel readers, you might have already used closures when adding database transactions.
Closures are defined using the function keyword followed by a list of parameters, and a body enclosed in curly braces. Let's take a look at a very simple example. We'll create a closure that adds two numbers together and then returns it:

$addition = function($a, $b) { return $a + $b; };

When to Use Closures or Arrow Functions

You should always choose the most appropriate tool for the job. So there's not really a right or wrong answer when it comes to choosing between closures and arrow functions. It's more about choosing the one that is most appropriate for the task at hand.
I'd strongly encourage you to use the one that allows you to write the most readable and maintainable code. For example, if you find that you're trying to cram a lot of complex logic inside your arrow functions, then this might be a sign that you should switch to closures instead. However, if you're writing simple functions that only contain a single statement, then arrow functions may be a more suitable approach.

Introduction

There may be times when you're building your Laravel application that you need to read a JSON file. I've often found myself needing to do this when I'm writing tests for an API integration and I want to read a dummy response that I'd previously saved in a JSON file. I've also needed to do this when I've been working with third-party services (such as Firebase) that provide a JSON file for you to pass to an SDK for authentication.

Reading JSON Files Using the "File" Facade

The File::json method is a simple wrapper around the json_decode function and File::get method. It allows you to read a JSON file from your local filesystem and return the contents as an array.
Previously, if you wanted to read a JSON file in your Laravel app, you could do something like this:

$contents = File::get(base_path('path/to/file.json'));
$json = json_decode($contents);

What is Markdown?

Before we touch any code, let's first take a look at what Markdown is, its history, and a few different examples of how you can use it. Markdown is a markup language that you can use to create formatted text, such as HTML. For example, in a Markdown file, you can write # Heading 1, which can be converted to the following HTML:Heading 1.It allows you to write, for example, documentation without prior knowledge of the intended output format (in this case, HTML). It allows you to create other elements, such as the following:

The Benefits of Using Markdown

As a developer, using Markdown can be quite beneficial. It can be used when writing documentation for you project, package, or library. You can also use it for technical writing, such as for a blog. In fact, if you've ever read over a "README" file on GitHub for a package that you're using in your project, it has been written using Markdown.
As we've already seen above, Markdown can help provide semantic meaning to your content; and in most cases, it doesn't need to be rendered for you to understand it. This is useful when multiple people are contributing to a file because familiarity with the styling of the output is not required. For example, the contents of the Laravel documentation are contained within a repository on GitHub (laravel/docs). It's completely open for anyone to contribute to it without needing to know about CSS classes or styling that the site will use during rendering. This means that anyone familiar with Markdown can jump right in and start contributing with a minimal amount of blockers.
Another significant benefit of using Markdown is its generally platform-agnostic nature. Have you ever created a document in Microsoft Word, opened it in Google Docs, and found that the document looks different? Maybe the tables aren't the same size? Alternatively, the text that goes perfectly to the end of the page in Word overflows onto the next page in Google Docs? Markdown reduces the likelihood of these issues by only worrying about structure, not styling. Instead, the styling would typically be placed on the HTML output.
Because Markdown usually only defines the structure and content rather than the styling, Markdown can be converted into many formats. Therefore, you can convert contents to both HTML and other formats, such as PDF, EPUB, and MOBI. You might want to use these formats if you're using Markdown to write an e-book that will be read on e-readers.

Introduction

If you've read any of my previous blog posts, you'll know that I like contributing to open-source projects whenever I get a chance to.
To be able to work on any packages, I typically have a "playground" Laravel project that I can use to test the changes that I make. This project is more or less a fresh Laravel installation with a few routes and controllers set up for me to test my contributions.
So this means that I need to be able to work on packages inside my project without directly updating any vendor files (in my project's vendor directory). To do this, I set a few options in the project's composer.json file so that I can work on packages locally.
This is a great way for you to experiment with possible features or changes for packages that you can then propose as pull requests.
In this short guide, I'm going to show you how you can do this yourself in your own projects if you're considering working on a package (whether it be a new package you're building or an existing one that you'd like to contribute to).

Local Package Development

Before we get started, I'm first going to assume that you have a fresh Laravel installation. You don't necessarily need to have one, but this does definitely make things easier by reducing the chances of clashes with other packages.
For the purpose of this guide, we're going to get install a fork of my Short URL package (ashallendesign/short-url) as a local package. If you're not sure what a fork is, you can check out this page on GitHub that describes it well.
As a side note, if you're interested in reading a bit more about using the Short URL package in your Laravel projects, you can my past article "How to Create Short URLs in Laravel".
We first want to let Composer know that we may have some packages stored locally that we can use when running things like composer require and composer update. To do this, we can add the following block to our project's composer.json file:

Introduction

In programming, it's important to make sure that your code is readable, maintainable, extendable and easily testable. One of the ways that we can improve all of these factors in our code is by using interfaces.

Intended Audience

This article is aimed at developers who have a basic understanding of OOP (object oriented programming) concepts and using inheritance in PHP. If you know how to use inheritance in your PHP code, this article should hopefully be understandable.

What Are Interfaces?

In basic terms, interfaces are just descriptions of what a class should do. They can be used to ensure that any class implementing the interface will include each public method that is defined inside it.
Interfaces are used to define the public methods that a class should include. It's important to remember that only the method signatures are defined and that they don't include the method body (like you would typically see in a method in a class). This is because the interfaces are only used to define the communication between objects, rather than defining the communication and behaviour like in a class. To give this a bit of context, this example shows an example interface that defines several public methods:

Introduction

Blade is a powerful templating engine that you can use in Laravel. It allows you to write clean templates using simple and understandable syntax to build some pretty complex layouts.
One of the cool features that I like about Blade is the ability to create your own custom directives. They allow you to define your own custom syntax that you can use in your Blade templates to make them more expressive and easier to read.

What are Blade Directives?

Blade directives are handy little shortcuts that you can add to your templates to reduce the need of using raw PHP. They start with the @ symbol, followed by the directive and any arguments.
If you've used Laravel before, you'll have likely interacted with Blade directives without realising. For example, you may have written an if statement in your Blade template using the @if and @endif directives

Creating Custom Blade Directives

Let's take a quick look at how you can write your own custom Blade directives.
We'll imagine that we want to write a custom directive that renders a Carbon date object in a specific human-friendly format. We'll call this directive @friendlyDateTime.
Before we try creating the new directive, let's take a look at how we would write the code to render a Carbon date object in the format we want without using a custom directive.