dmitry.g.ivanov

dmitry.g.ivanov

Member Since 3 Years Ago

Odessa

Software Engineer at IDF

Experience Points 144,980
Experience Level 29

20 experience to go until the next level!

In case you were wondering, you earn Laracasts experience when you:

  • Complete a lesson — 100pts
  • Create a forum thread — 50pts
  • Reply to a thread — 10pts
  • Leave a reply that is liked — 50pts
  • Receive a "Best Reply" award — 500pts
Lessons Completed 1434
Lessons
Completed
Best Reply Awards 0
Best Reply
Awards
  • start-engines Created with Sketch.

    Start Your Engines

    Earned once you have completed your first Laracasts lesson.

  • first-thousand Created with Sketch.

    First Thousand

    Earned once you have earned your first 1000 experience points.

  • 1-year Created with Sketch.

    One Year Member

    Earned when you have been with Laracasts for 1 year.

  • 2-years Created with Sketch.

    Two Year Member

    Earned when you have been with Laracasts for 2 years.

  • 3-years Created with Sketch.

    Three Year Member

    Earned when you have been with Laracasts for 3 years.

  • 4-years Created with Sketch.

    Four Year Member

    Earned when you have been with Laracasts for 4 years.

  • 5-years Created with Sketch.

    Five Year Member

    Earned when you have been with Laracasts for 5 years.

  • school-session Created with Sketch.

    School In Session

    Earned when at least one Laracasts series has been fully completed.

  • welcome-newcomer Created with Sketch.

    Welcome To The Community

    Earned after your first post on the Laracasts forum.

  • full-time-student Created with Sketch.

    Full Time Learner

    Earned once 100 Laracasts lessons have been completed.

  • pay-it-forward Created with Sketch.

    Pay It Forward

    Earned once you receive your first "Best Reply" award on the Laracasts forum.

  • subscriber-token Created with Sketch.

    Subscriber

    Earned if you are a paying Laracasts subscriber.

  • lifer-token Created with Sketch.

    Lifer

    Earned if you have a lifetime subscription to Laracasts.

  • lara-evanghelist Created with Sketch.

    Laracasts Evangelist

    Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.

  • chatty-cathy Created with Sketch.

    Chatty Cathy

    Earned once you have achieved 500 forum replies.

  • lara-veteran Created with Sketch.

    Laracasts Veteran

    Earned once your experience points passes 100,000.

  • 10k-strong Created with Sketch.

    Ten Thousand Strong

    Earned once your experience points hits 10,000.

  • lara-master Created with Sketch.

    Laracasts Master

    Earned once 1000 Laracasts lessons have been completed.

  • laracasts-tutor Created with Sketch.

    Laracasts Tutor

    Earned once your "Best Reply" award count is 100 or more.

  • laracasts-sensei Created with Sketch.

    Laracasts Sensei

    Earned once your experience points passes 1 million.

  • top-50 Created with Sketch.

    Top 50

    Earned once your experience points ranks in the top 50 of all Laracasts users.

18 Dec
7 months ago
14 Dec
7 months ago

dmitry.g.ivanov left a reply on Laravel Forge + Redis

@themsaid Thank you for your response!

Now I understand it.

We can use Redis with predis/predis or with PhpRedis (which is "PHP Redis extension", it is the same).

I was confused by one of the projects where both were used in tests, so I thought that predis/predis required redis.so (and I supposed that PhpRedis is yet another extension), which is not true.

@themsaid What is the best practice for "requiring" predis/predis?

I mean, I don't need it on local environment, I need it only on production.

But Composer doesn't have something like require-prod...

So, I can "composer require" it and have loaded on every environment (which is not too bad but doesn't feel very clean...)

Or I can "composer require" it on production, but in that case, I would have unclear "git status" on production, which is worse for my eyes.

(As far as I know, there is no possibility to install the package without modifying the composer.json/composer.lock files.)

dmitry.g.ivanov left a reply on Laravel Forge + Redis

@gorby Yes, I use Redis on Forge too.

But I want to understand how does it work.

In order to use Redis locally, I have to install redis PHP extension.

But I can't see it installed on Forge. So, I wonder how does it work then?

13 Dec
7 months ago

dmitry.g.ivanov left a reply on Laravel Forge + Redis

@ejdelmonico Yes, I know it.

But your answer doesn't answer my question)

12 Dec
7 months ago

dmitry.g.ivanov started a new conversation Laravel Forge + Redis

How does Laravel Forge use Redis?

I've found redis-server and redis-tools installed via apt:

apt list --installed
...
redis-server/bionic,now 5:5.0.2-3chl1~bionic1 amd64 [installed]
redis-tools/bionic,now 5:5.0.2-3chl1~bionic1 amd64 [installed,automatic]

But I can't find redis php extension installed, neither in php -m, nor in php -i.

However, I've checked - it works somehow.

Also, does anyone know - Laravel Forge pre-install PHPRedis by default or not?

11 Dec
7 months ago

dmitry.g.ivanov started a new conversation Weather Forecast In PHP

Hey, guys!

I want to introduce my new package for the Weather Forecast in PHP: https://github.com/dmitry-ivanov/dark-sky-api

It is a stand-alone PHP package, with Laravel support implemented.

Check the readme file for the basic usage examples and more detailed explanations in my recent article: https://medium.com/@dmitry.g.ivanov/weather-forecast-in-php-95bca6b0ed18

Hope it would be useful for you!

16 Oct
9 months ago

dmitry.g.ivanov started a new conversation Laravel Dark Sky (Weather Forecast)

Hey, guys!

I've created the package for getting the weather forecast (and past weather conditions) using the Dark Sky API.

The syntax is very simple:

use DarkSky;

$forecast = (new DarkSky($latitude, $longitude))->forecast();

You can get the forecast, or do the "time machine" requests for multiple dates:

$weather = (new DarkSky($latitude, $longitude))->timeMachine(['1986-05-11', '1987-05-11', '1988-05-11']);

Multiple requests are executed concurrently for you, so you don't have to bother with that. Also, the response body is automatically gzipped for you for better performance.

You can change the language, the units system and other parameters on the fly, or in your config file.

Please, check the readme file for more information:

https://github.com/dmitry-ivanov/laravel-dark-sky

Hope it would be useful for someone!

10 Aug
11 months ago

dmitry.g.ivanov left a reply on Pass Associative Array From Blade To Vuejs

@kfirba Hey! I'm using the same solution, but PHPStorm Doesn't understand that syntax and showing "expression expected" error for such syntax.

Do you know how to learn IDE that it's okay? Thanks!

dmitry.g.ivanov left a reply on Can't Pass Data From Blade To Vue Through A Prop

@gbrits I'm using the same solution, however my IDE (PHPStorm) doesn't like that syntax, it shows an error - expression expected.

I have Laravel plugin, Blade and Vue - all enabled.

Does anyone know how to learn PHPStorm that it's okay?

24 Jul
11 months ago

dmitry.g.ivanov left a reply on Laravel Wikipedia (MediaWiki) Grabber

Thank you for your kind words, @Loach, @m7vm7v !

23 Jul
11 months ago

dmitry.g.ivanov started a new conversation Laravel Wikipedia (MediaWiki) Grabber

Hi, guys!

I've just finished new package - for grabbing Wikipedia (or another MediaWiki) page.

Base usage is very simple:

use Wikipedia;

echo (new Wikipedia)->page('Donald Trump');

It grabs a page with the images, galleries, audio and video files and returns HTML in the specified format. It can be plain HTML, Bulma or Bootstrap (3 and 4).

Also, an information about grabbed page can be retrieved. Such as id, title, page status, etc.

Please, see readme for more info: https://github.com/dmitry-ivanov/laravel-wikipedia-grabber


Hope it would be useful for someone!
10 Feb
2 years ago

dmitry.g.ivanov started a new conversation Dusk Vs BrowserKit?

Hi, guys!

Laravel 5.4 released, and testing api changed, so 5.3 tests are no longer supported without backwards compatibility package: https://github.com/laravel/browser-kit-testing

So, after migrating my project to 5.4, I've started to remove browser-kit-testing dependency, and migrated my tests to Dusk. I've done with a few tests and saw that a speed is a really slow compared to BrowserKit. So, I've changed my plan and I've tried to fix my tests according to the new 5.4 api, but there are not all assertions implemented in 5.4. Even such simple things as "assertSeeLink" are absent.

So, I have a situation when my simple project tests are running ~8 sec with BrowserKit can't be migrated to 5.4 http testing api, and probably can be migrated to Dusk - but with such a slow speed, which makes it not interesting for me.

From the other hand, I don't want to have that "backwards compatibility" dependency, and I understand that the same question would be relevant for the new 5.4 projects. Any thoughts?

Thanks and have a great day!

12 Dec
2 years ago

dmitry.g.ivanov started a new conversation Laravel Testing Tools

Hi there!

I've created a package, where I'm collecting Laravel-specific testing helpers and asserts. For example, methods for environment emulation, methods to run console commands directly through the object, different types of assertions - assertCollectionsEqual, seeInDatabaseMany, seeInSchedule, etc.

New helpers and assertions are welcomed! https://github.com/dmitry-ivanov/laravel-testing-tools

Hope it would be useful for someone.

13 Sep
2 years ago

dmitry.g.ivanov started a new conversation Simple Database Profiler

Hi there!

Sometimes it's needed to check all of your database queries.

You can achieve this in a different ways:

  • listen db queries via DB class;
  • add separate method in your AppServiceProvider;
  • use one of the extensions or packages, for example, Laravel DebugBar;
  • etc;

It's pretty simple task, really. But, that copy-paste process, or using of the heavy packages is boring. I've created very simple package just for db profiling: https://packagist.org/packages/illuminated/db-profiler https://github.com/dmitry-ivanov/laravel-db-profiler

It enabled only for local environment. It supports http and console applications both. Use vvv request param, or -vvv option to turn it on. Please, check readme for more details.

Hope it would be useful for someone! Thanks and have a great day!

03 Sep
2 years ago

dmitry.g.ivanov started a new conversation Dynamic Class Aliases In Package

Hi!

Let's pretend you have a package. And you want some class from your package would be available in a simple way, through class alias (as facade). The common solution is just to add an alias to config/app.php in aliases array:

    'aliases' => [

       // ...
        'FooBar' => My\SuperPackage\FooBar::class,

    ],

Now you can use FooBar like this:

FooBar::doSomething();

But, the bad thing that people using your package have to add those aliases by themselves.

The good thing is that can be done automatically in your service provider:

use Illuminate\Foundation\AliasLoader;
use My\SuperPackage\FooBar;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function register()
    {
        $this->app->booting(function() {
            $loader = AliasLoader::getInstance();
            $loader->alias('FooBar', FooBar::class);
        });
    }
}

Hope it would be useful for someone! Thanks and have a great day!

26 Jul
2 years ago

dmitry.g.ivanov left a reply on Where Are You All From?

Odessa, Ukraine

dmitry.g.ivanov left a reply on Task Scheduling In Packages

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

dmitry.g.ivanov left a reply on How To Best Way To Registry Scheduler In 3rd Packages

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

dmitry.g.ivanov left a reply on Using Scheduler From A Package

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

dmitry.g.ivanov left a reply on Binding Schedule In Laravel Package

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

dmitry.g.ivanov left a reply on Using The Scheduler From A Package

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

dmitry.g.ivanov left a reply on Package Console Command Schedules

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}
19 Jul
2 years ago

dmitry.g.ivanov started a new conversation SEO Series, Please?

Hi, everyone! Hi, @JeffreyWay!

Thanks for your work, videos are really awesome! As a proposition - it would be great to have some SEO series here, at Laracasts.

After creating a project (and we do have series here at Laracasts, which are covering that process fully, from the moment of buying a domain to a production), so after creating a project - everyone would have that question. What a hack is SEO, and what should I do now? What are at least "must have" basic steps at this direction, and what should I do in future?

Hope that other people would vote for that request too. Thanks and have a great day!

16 Jul
3 years ago

dmitry.g.ivanov left a reply on String Literals Vs Consts Overuse?

Actually, as it was expected there is no correct answer on this question. All depends on situation. Sometimes it useful to have a constant, and there are definitely some benefits of that. But sometimes, it is not needed and simple string literal is okay.

Maybe the count of usages and the scope of usages are the criteria to make the choice.

Anyway, you have to find your golden mean which is suitable for you and your projects.

dmitry.g.ivanov left a reply on Console Command Call In Background

@jimmck Ah, got it! Sorry, but I don't actually understand why would you ever need such custom composer script?

Helper function provides an ability to call artisan command in background from code (from another process).

For example, your foo command needs to call your bar command, but actually doesn't care about the results of bar execution and doesn't need to wait till bar is finished. So, you call bar in background, and foo is ready to go on immediately.

In the case of command line call - you just open terminal, run command. Want some more - just open another terminal and call another one. I don't understand what would be a difference between simple call from command line and "call in background" from command line? You have to be in some process to make "call in background" have sense.

15 Jul
3 years ago

dmitry.g.ivanov left a reply on Console Command Call In Background

@jimmck Sure, it is available through composer. Just run in your project:

composer require illuminated/helper-functions

And all of existing helper functions (including call_in_background()), and the new ones - would be available in your project.

Please, see readme for more information: https://github.com/dmitry-ivanov/laravel-helper-functions

dmitry.g.ivanov started a new conversation Console Command Call In Background

Hi there!

If you need to call artisan command from code, you can use Laravel Artisan facade class: https://laravel.com/docs/5.2/artisan#calling-commands-via-code

But what about background calls?

I've made a simple helper function for that.

call_in_background() Calls artisan console command in background, with optional before and after sub-commands:

call_in_background('foo');

// "php artisan foo" would be called in background
call_in_background('foo:bar baz', 'sleep 0.3');

// "sleep 0.3 && php artisan foo:bar baz" would be called in background

If you'd like to use it, this helper is available in my package with other helper functions: https://github.com/dmitry-ivanov/laravel-helper-functions https://packagist.org/packages/illuminated/helper-functions

Hope it would be useful for someone. Thanks and have a great day!

07 Jul
3 years ago

dmitry.g.ivanov started a new conversation Console Command Logger (with Email Notifications)

Hi there!

Just wanted to write few words about a package I've just released: https://github.com/dmitry-ivanov/laravel-console-logger https://packagist.org/packages/illuminated/console-logger

Often I'm working with a projects, which have a lot of scheduled commands (cron jobs). These crons can be very simple - just make some trivial operations with database, generate some report, etc... But also, they can be really complex - some interaction with external services, getting data from them, pushing data to them, etc.

So, it's very useful for me to have some kind or text logs (separate logs for each command) and, which is even more important, - some kind of monitoring tool, which would notify me if something went wrong.

This is exactly what illuminated/console-logger package do.

After installing package through composer, all you have to do is use additional trait in your command class and specify notification recipients. Package is fully customizable and has a lot of cool features, such as: logs separated by commands and dates, auto-rotation (only latest 30 files are stored), global error handler (it would catch ALL types of possible errors - even PHP notices for you), email notifications with optional deduplication if needed, ability to save notifications to database, set of useful info added to your logs, context support with nice dumps, etc....

I've tried to describe all of these features really good in readme, there are a lot of examples, and even notification screenshot example. So, please, check it for more information. Feel free to ask me if you would have some questions about the package.

Hope it would be useful for someone. Thanks!

10 Jun
3 years ago

dmitry.g.ivanov left a reply on SPAM Protection?

Yep, a lot of trash today)

01 Jun
3 years ago

dmitry.g.ivanov started a new conversation Console Command Mutex (without Overlapping)

Hi there!

As we all know, there are some mechanisms in Laravel, which help you to prevent schedule tasks overlapping: https://laravel.com/docs/5.2/scheduling#preventing-task-overlaps

You can just use withoutOverlapping method, and this will protect you from running more than one instance of your schedule command at the same time.

But what if someone call your protected schedule command from console manually? withoutOverlapping method wouldn't help in such situation. It handles just scheduled executions of the command.

So, I've found that it is a problem for one of my projects, and I've created a small package, which will prevent Laravel console commands overlapping, no matter from where it was called. Few times manually, from schedule + manually, etc. No matter - it just protects your command from overlapping.

Here are the links, already available through composer via packagist: https://github.com/dmitry-ivanov/laravel-console-mutex https://packagist.org/packages/illuminated/console-mutex

See readme please, but generally speaking, all you have to do is use Illuminated\Console\WithoutOverlapping trait in your console command class:

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminated\Console\WithoutOverlapping;

class Foo extends Command
{
    use WithoutOverlapping;

    // ...
}

And now your command is protected against overlapping:

➜ php artisan foo:bar baz
Command is running now!

Also, there are several strategies for preventing overlapping:

  • file (default)
  • mysql
  • redis
  • memcached

See readme for more information.

Hope it would be useful for someone!

21 May
3 years ago

dmitry.g.ivanov left a reply on String Literals Vs Consts Overuse?

@tfevens, as @martinbean said - probably you get an error because you didn't specify full class name (with namespace included).

According to my User class example, which is in the first post of the topic, that works fine in views:

@if (\App\User::ROLE_ADMIN == 'admin')
    Ridiculous check works! :)
@endif

But let's try to return to the main theme of the topic :) Are string literals in code always bad? We're NOT talking about integers, just strings please)

PS: Actually, I'm still using them, always) But just want to hear more opinions from other developers.

18 May
3 years ago

dmitry.g.ivanov left a reply on Package Migration Timestamp

I've just added timestamps to my package migration filenames by myself. So, my package migrations look like:

./database/migrations/2016_05_11_000001_migration1.php
./database/migrations/2016_05_11_000002_migration2.php
./database/migrations/2016_05_11_000003_migration3.php
...

dmitry.g.ivanov left a reply on Publishing Config And Migrations From Included Package In Laravel

Here is the code of your package service provider:

<?php

namespace Foo\Bar;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function register()
    {
        $this->mergeConfig();
    }

    public function boot()
    {
        $this->publishConfig();
        $this->publishMigrations();
    }

    private function mergeConfig()
    {
        $path = $this->getConfigPath();
        $this->mergeConfigFrom($path, 'bar');
    }

    private function publishConfig()
    {
        $path = $this->getConfigPath();
        $this->publishes([$path => config_path('bar.php')], 'config');
    }

    private function publishMigrations()
    {
        $path = $this->getMigrationsPath();
        $this->publishes([$path => database_path('migrations')], 'migrations');
    }

    private function getConfigPath()
    {
        return __DIR__ . '/../config/bar.php';
    }

    private function getMigrationsPath()
    {
        return __DIR__ . '/../database/migrations/';
    }
}

Then, in a project, which is using your package (after composer require foo/bar is done, of course) - add in config/app.php:

'providers' => [
    // ...
    Foo\Bar\ServiceProvider::class,
],

And now you can publish your config and migrations:

php artisan vendor:publish --provider="Foo\Bar\ServiceProvider"
05 May
3 years ago

dmitry.g.ivanov started a new conversation String Literals Vs Consts Overuse?

Hi there!

A lot of developers (including me) - are using consts for almost each primitive (int, string) in the code. When it comes to integers (so called "magic numbers") - it perfectly makes sense, but I have some doubts according strings. I understand that consts are more IDE-friendly, they are protecting me from typos, it's easy to find, to change... But how often actually do we need to find, or change them? How often do we create const with the name which exactly match it's value? Does it makes sense?

For example:

class User extends Authenticatable
{
    // ...
    const ROLE_ADMIN = 'admin';
    const ROLE_MODERATOR = 'moderator';
    const ROLE_USER = 'user';
    // ...
}
class AdminsController extends Controller
{
    public function __construct()
    {
        $this->middleware('role:' . User::ROLE_ADMIN);
        // vs
        $this->middleware('role:admin');
    }
}

Without consts code can be more simple, clear and readable. Do we need that strict practice? I've searched through Laravel code - and it has only 19 declared class consts. Taylor is mostly using string literals in Laravel.

I understand that this is the question of preference, and probably there is no just one correct answer - all depends of situation. But can we at least say that using string literals instead of consts overuse is NOT a bad practice? Are there any "best practices"? It would be very interesting to hear @JeffreyWay here, if possible.

Thanks and have a great day!

04 May
3 years ago

dmitry.g.ivanov left a reply on Resource Validation & Authorize Best Practices

Thanks for your replies!

So, my final solution is using simple TaskRequest for validation only, and separate TaskPolicy for authorization:

class TasksController extends Controller
{
    // ...
    public function edit(Task $task)
    {
        $this->authorize($task);
        return view('tasks.edit');
    }

    public function update(TaskRequest $request, Task $task)
    {
        $this->authorize($task);
        $task->update($request->all());
        return Redirect::route('tasks.index');
    }

    public function destroy(TaskRequest $request, Task $task)
    {
        $this->authorize($task);
        $task->delete();
        return Redirect::route('tasks.index');
    }
    // ...
}
class TaskRequest extends Request
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            'name' => 'required|min:10',
            'description' => 'required',
        ];
    }
}
class TaskPolicy
{
    use HandlesAuthorization;

    public function edit(User $user, Task $task)
    {
        return $user->owns($task);
    }

    public function update(User $user, Task $task)
    {
        return $user->owns($task);
    }

    public function destroy(User $user, Task $task)
    {
        return $user->owns($task);
    }
}

Which is also gives a beautiful authorization checks syntax for the views:

@can('edit', $task)
    <a href="{{ route('tasks.edit', [$task->id]) }}">Edit</a>
@endcan
@can('destroy', $task)
    {!! Form::open(['route' => ['tasks.destroy', $task->id], 'method' => 'delete']) !!}
        <button type="submit">Delete</button>
    {!! Form::close() !!}
@endcan

PS: You can find more info about this solution (acl) in laravel documentation: https://laravel.com/docs/5.2/authorization#policies Or here, at Laracasts (ACL, last four lessons): https://laracasts.com/series/whats-new-in-laravel-5-1

27 Apr
3 years ago

dmitry.g.ivanov started a new conversation CRUD Authorize Best Practices

Hi there!

I have typical simple resource controller - TasksController. Each Task is owned by a User. I want to protect Tasks from being updated or deleted NOT by their owner User. Also, there are some simple validations for tasks form.

So, here is my solution:

class TasksController extends Controller
{
    // ...
    public function store(TaskRequest $request)
    {
        $task = Auth::user()->tasks()->create($request->all());
        return Redirect::route('tasks.index');
    }

    public function update(TaskRequest $request, Task $task)
    {
        $task->update($request->all());
        return Redirect::route('tasks.index');
    }

    public function destroy(TaskRequest $request, Task $task)
    {
        $task->delete();
        return Redirect::route('tasks.index');
    }
    // ...
}

And my TaskRequest class:

class TaskRequest extends Request
{
    public function authorize()
    {
        if (empty($this->task)) {
            return true;
        }

        $user = Auth::user();
        return $this->task->isOwnedBy($user);
    }

    public function rules()
    {
        if (request()->isMethod('DELETE')) {
            return [];
        }

        return [
            'name' => 'required|min:10',
            'description' => 'required',
        ];
    }
}

So, performing authorize checks by a common injected TaskRequest object, but I'm not sure is that a best solution? I don't really like unused variable TaskRequest $request in TasksController@destroy. And I don't really like that mix of logic in my TaskRequest class.

Any ideas? Thanks and have a great day!