3 minutes ago

Laravel is a great framework with fantastic documentation — but it can be a little overwhelming. There are so many ways to accomplish the same task. How do you know which way is the best?

This course will break down the most important things to learn about Eloquent, the ORM that is a central part of Laravel. There are 14 Lessons that take about 10–15 minutes each to accomplish.

At the end of the three weeks you will have a solid workflow and be able to use the Artisan tools to quickly design and create new applications.

Who is this course for?

This is for people who are relatively new to Laravel, are simply interested in learning more about the Eloquent ORM, or who feel like they missed out on some important things from teaching themselves and would like to learn some of the techniques they’ve seen on Laracasts or other tutorials.

Lessons

About Jeff Madsen

Jeff Madsen is a free-lance developer living in Japan. He blogs about Laravel, Vue.js and other web development. Follow him on Twitter or Medium, or join his weekly Laravel Quick Tips newsletter to learn more about the framework.

Originally published at laravelfeed.com.

PHP 7 performance improvements (4/5): References mismatch

Julien Pauli, PHP contributor and release manager, details what changed between PHP 5 and PHP 7, and how to migrate and make effective use of the language optimizations. All statements are documented with specific examples and Blackfire profiles. Fourth episode: References mismatch generating no overhead.

The following is the 4th episode of our blog series on PHP 7 performance improvements, detailed by Julien Pauli PHP Contributor and Release Manager. We will update this introduction with links to all other articles when they are published.

Read episode 1: Packed arrays

Read episode 2: ints/floats are free in PHP 7

Read episode 3: Encapsed strings optimization

Reference mismatch happens when you pass a non-ref variable to a function argument passed-by-ref, or the opposite. Something like this:

function foo(&$arg) { } $var = 'str'; foo($var);

Do you know what horrible things happen under the hood in the PHP 5 engine? In PHP 5, whenever there is a reference mismatch, the engine is forced to duplicate the variable before passing it as an argument to a function. As you probably guessed, if the variable contains something big, like a several-thousands-entries array or a big chunk of string; the copy will take a lot of time.

This is because of the way variables and references used to work into PHP 5. When going into the body function, the engine doesn’t know yet if you will change the argument value. If you are, then as the argument is taken by reference, the change must be reflected outside if a reference variable were passed. What if it was not the case (as in our example)? The engine must then create a reference, from the non-reference variable you passed it in the function call. This procedure leads the engine to fully duplicate the variable content in PHP 5 (calling a lot of memcpy() on very sparse pointers, leading to tons of slow memory accesses).

In PHP 7, when the engine wants to create a reference from a non-reference variable, it just wraps the latter into the newly created former, that’s all. There is no memory copy, anywhere. This is because variables work in a very different way internally in PHP 7, and references have been deeply reworked.

Look at this piece of code:

Originally published at laravelfeed.com.

I want to look at two PHP functions: eval and exec. They’re so often thrown under the sensible-developers-never-use-these bus that I sometimes wonder how many awesome applications we miss out on.

Like every other function in the standard library, these have their uses. They can be abused. Their danger lies in the amount of flexibility and power they offer even the most novice of developers.

Let me show you some of the ways I’ve seen these used, and then we can talk about safety precautions and moderation.

Dynamic Class Creation

The first time I ever saw dynamic class creation was in the bowels of CodeIgniter. At the time, CodeIgniter was using it to create ORM classes. eval is still used to rewrite short open tags for systems that don’t have the feature enabled…

More recently, though, my friend Adam Wathan tweeted about using it to dynamically create Laravel facades. Take a look at what the classes usually look like:

namespace Illuminate\Support\Facades; class Artisan extends Facade { protected static function getFacadeAccessor() { return "Illuminate\Contracts\Console\Kernel"; } }

This is from github.com/laravel/framework/blob/5.3/src/Illuminate/Support/Facades/Artisan.php

These facade classes aren’t facades in the traditional sense, but they do act as static references to objects stored in Laravel’s service locator class. They project an easy way to refer to objects defined and configured elsewhere, and have benefits over traditional static (or singleton) classes. One of these benefits is in testing:

public function testNotificationWasQueued() { Artisan::shouldReceive("queue") ->once() ->with( "user:notify", Mockery::subset(["user" => 1]) ); $service = new App\Service\UserService(); $service->notifyUser(1); }

…and though these facades are simple to create, there are a lot of them. That’s not the kind of code I find interesting to write. It seems Adam felt the same what when we wrote the tweet.

So, how could we create these facade classes dynamically? I haven’t seen Adam’s implementation code, but I’m guessing it looks something like:

function facade($name, $className) { if (class_exists($name)) { return; } eval(" class $name extends Facade { protected static function getFacadeAccessor() { return $className::class; } } "); }

That’s a neat trick. Whether of not you use (or even like) Laravel facades, I’m guessing you can see the benefits of writing less code. Sure, this probably adds to the execution time of each request, but we’d have to profile performance to decide if it even matters much.

I’ve used a similar trick before, when working on a functional programming library. I wanted to create the supporting code to enable me to write applications using fewer (if any) classes. This is what I used eval to create:

Originally published at laravelfeed.com.

There are tons of reasons to do laravel development on Homestead. And though you might be convinced to use it, it is not always very simple to be “up and running” within minutes. Laravel’s official documentation on installing Homestead on Windows and Mac is pretty clear. But sometimes, the process is not as straight forward as shown in the documentation. There are a lot of 3rd party software involved and sometimes they create problems. I will be guiding you through the installation and configuration of Laravel Homestead while preventing the common errors from occurring.

Introduction

You may already know what Laravel Homestead is and what VirtualBox and Vagrant are. But just in case you don’t know then here is a brief introduction for them.

VirtualBox:

It is a software which helps you run a different Operating System on top of another Operating System. For example you have Windows installed on your machine and you want to use a Ubuntu on it as well. You can do it through VirtualBox. As the name Implies, it creates a Virtual Box or a Virtual Machine inside which you can install other operating systems. In this case, Windows will be your Host OS while Ubuntu will be your Guest OS.

Vagrant

Vagrant is a utility which help us automatically manage Virtual Machines inside Virtual Box. It also help us to ship our software to others or even to the production server with same environment in which we have coded it. Most of Php developers uses Windows or Mac to code on. The main problem with these OSs is that when we ship our software to a Linux environment, it breaks. Vagrant help us ship the software along the environment in an file format known as box e.g Homestead.box

Laravel Homestead

Homestead is a group of software and commands for Vagrant. The official list of what’s included in it can be found here. It automatizes and facilitates the installation of required software for a Virtual Server like Ubuntu, Nginx, MySQL etc.

In short, by combining VirtualBox, Vagrant and Laravel Homestead, one will be able to provide a production environment to Laravel inside Windows or Mac. So you can have all your favorite apps and software of your favorite OS along with the benefit of having a full fledged production level server running Ubuntu and Nginx. Now follow the following steps to get Laravel Homestead up on Windows.

Step 1: Downloading Files

Originally published at laravelfeed.com.

PHP frameworks can really speed up your development process. They provide you with a stable foundation to start from, so that you can spend time developing the important parts of your application rather than reinventing the wheel.

But the proliferation of different PHP frameworks also means that there’s a learning curve involved. As well as learning PHP, you need to learn the workings of each framework, or at least of the ones you’re planning to use.

So we’ve got you covered in this article, with details of 11 courses that will get you up to speed with Laravel, Lumen, Phalcon, Symfony, and a range of other PHP frameworks.

1. Get Started With Laravel 5

Laravel is a PHP framework for modern web apps. Recently upgraded to version 5, Laravel is a mature system that continues to win support due to its elegance and stability. Laravel ships with built-in support for database migrations, object-relational mapping, routing, and authentication, making it easier for developers to start and maintain their work.

In this course, you’ll start by learning the basics of the Laravel framework with instructor Jason Lewis. You’ll begin by preparing a dev environment and learning how to configure Laravel. Then you’ll move on to learn foundational topics such as routing and requests, responses, views, sessions, emails, forms, and using databases.

2. Build a CMS With Laravel

Originally published at laravelfeed.com.

PHP 7.1–8 New Features you need to know

4 minutes ago

PHP 7.1, the new minor version of PHP will be released on December 1st, with a number of new features, changes, and bug fixes. While we wait for it’s release, let’s look at some of the awesome features in PHP 7.1. Like,

• iterable pseudo type
• Closure from callable
• Square bracket syntax for list()
• Support for keys in list
• Class constant visibility
• Nullable types
• Void functions
• Catching Multiple Exception Types

I will also link to the corresponding RFCs for your reference.

Before we start: Would you like to try out PHP 7.1 without messing up the existing environment? Docker is your best friend! PHP 7.1 can be easily set up using Docker with one of these images.

To start a php 7.1 container:

docker run -v /Users/apple/Workplace/php/:/php -it php:7.1-rc bash

This will download (if not locally existing) the docker image for php:7.1-rc, start the container and take you inside the container using bash prompt. -v /Users/apple/Workplace/php/:/php option maps /Users/apple/Workplace/php directory of the host machine to /php directory inside the docker container. So everything inside /Users/apple/Workplace/php will be available in /php directory of the container.

Now we will move inside the /php directory.

cd /php

Cool! We are now ready to try out the new features in PHP 7.1.

iterable pseudo type

Originally published at laravelfeed.com.

The other day I had an issue with several middleware classes for a Laravel application and I wanted to verify that they were working as expected. Sounds like a job for dedicated unit tests, but I hadn’t tested custom middleware in isolation before, and figuring out how to do so took a while.

Laravel middleware accepts an instance of Illuminate\Http\Request, itself based on the Symfony request object, as well as a closure for the action to take next. Depending on what the middleware does, it may return a redirect or simply amend the existing request or response. So in theory you can instantiate a request object, pass it to the middleware, and check the response. For middleware that does something simple, such as redirecting users based on certain conditions, this is fairly straightforward.

In this example we have a fairly useless piece of middleware that checks to see what the route is for a request and redirects it if it matches a certain pattern:

namespace App\Http\Middleware; use Closure; class RedirectFromAdminMiddleware { /** * Handle an incoming request. * * @param \Illuminate\Http\Request $request * @param \Closure $next * @return mixed */ public function handle($request, Closure $next) { if ($request->is('admin*')) { return redirect('/'); } return $next($request); } }

While this example is of limited use, it wouldn’t take much work to develop it to redirect conditionally based on an account type, and it’s simple enough to demonstrate the principles involved. In these tests, we create instances of Illuminate\Http\Request and pass them to the middleware’s handle() method, along with an empty closure representing the response. If the middleware does not amend the request, we get the empty response from the closure. If it does amend the request, we get a redirect response:

Originally published at laravelfeed.com.

So in PHPUnit it is common to reuse code by inheritance. Even by now we often create some base class providing common functionality. This works fine and is OK if this really defines an “is a”-relationship. Let’s continue with an example from our Page Object test repository. The patterns described here are usually not required for Unit Tests (which you should always also write) but mostly for integration or functional tests.

An Example

The example repository implements functional tests for a website using the Page Object pattern. This means that the tests access a website and assert on its contents, try to fill forms, submit them and click links. Such tests are a useful part of your test mix, but should never be your only tests.

Let’s see the options for code reuse we employ in this little test project — and the reasoning behind it. We start with a simple test case:

class LoginTest extends FeatureTest { public function testLogInWithWrongPassword() { $page = (new Page\Login($this->session))->visit(Page\Login::PATH); $page->setUser(getenv('USER')); $page->setPassword('wrongPassword'); $newPage = $page->login(); $this->assertInstanceOf(Page\Login::class, $newPage); } // … }

This test case extends from a base class FeatureTest to re-use its functionality. The base class uses PHPUnits setUp() method to setup and start the mink test driver which will act as a browser to access the website. And it provides a default tearDown() method to reset the browser state again.

In this case the inheritance defines a clear “is a” relationship with the FeatureTest and it overwrites default methods in the PHPUnit stack which should be overwritten in any feature test. The FeatureTest again extends an IntegrationTest which is empty in this example but normally would provide access to the application stack to reset a database, access random services or something similar. We just do not need anything like this in this little test project. Since functional tests can be considered a superset of integration tests this is fine again and provides common functionality which belongs to all tests of this type.

Traits

Originally published at laravelfeed.com.

Refactoring to Collections is a great book by Adam Wathan where he demonstrates, how you can avoid loops by using collections. It sounds great from the beginning, but you need to practice it, in order to be able to use it in your own projects. This is why I refactored some of my older projects. I want to share these examples today with you.

Note: Code examples are from Laravel projects where collections are built-in.

Example 1

Here I needed to built a string from an array to create an unique cache key for given search filters. When you first look at the before and after examples, you could question if the collection version is a better choice here. This is because it looks a little bit more complex. But this is just the first impression. The collection version of this code has some great benefits:

• as always with collections, the code tells you more about what is happening
• it separates steps and helps you do one thing after the other
• it is easier to add more functionality like adding a filter

Before

... $returnString = ''; foreach ($filters as $key => $item) { $returnString .= $key .':' . $item . ','; }

Afterwords

$returnString = collect($filters) ->map(function($value, $key) { return $key . ':' . $value; })->implode(',');

Example 2

This second example is from a private project of mine where I work with recipes and recipe steps. When you create a new recipe you need to store recipe steps too. We are mapping an input array of recipe step data to a new collection of recipeSteps objects. Collections are also great here, because we can use them with the saveMany method like this: $newRecipe->recipeSteps()->saveMany($recipeSteps);

Before

... $steps = $input['step']; $recipeSteps = []; foreach ($steps as $step) { $recipeSteps[] = new RecipeStep(['recipe_id' => $recipeId, 'desc' => $step['desc']]); }

Afterwords

... $steps = collect($input['step']) $recipeSteps = $steps->map(function($step) use ($recipeId) { return new RecipeStep(['recipe_id' => $recipeId, 'desc' => $step['desc']]); });

Example 3

Originally published at laravelfeed.com.

PHP 7 performance improvements (3/5): Encapsed strings optimization

2 minutes ago

Julien Pauli, PHP contributor and release manager, details what changed between PHP 5 and PHP 7, and how to migrate and make effective use of the language optimizations. All statements are documented with specific examples and Blackfire profiles. Third episode: Encapsed strings optimization dropping CPU usage by a factor of 10.

The following is the 2nd episode of our blog series on PHP 7 performance improvements, detailed by Julien Pauli PHP Contributor and Release Manager. We will update this introduction with links to all other articles when they are published.

Read episode 1: Packed arrays

Read episode 2: ints/floats are free in PHP 7

Encapsed strings are strings where in-variable scan occur. Those are strings declared using double-quotes or the Heredoc syntax. The algorithm needs to analyze the string, and separate each string part from the variable part. Consider this example :

$a = 'foo'; $b = 'bar'; $c = "I like $a and $b";

When analyzing the $c string, the engine must run so that at the end, $c contains the “I like foo and bar” string. This process has been optimized in PHP 7 as well.

Here what PHP5 does:

Originally published at laravelfeed.com.