Станислав Почепко

о компоненте узнал из вашего вопроса, довольно интересный.

добавляет стейт машину в симфони. будет удобно когда сущности имеют некие состояния, например задача и ее состояния (открыта, выполняется, требуется проверка, закрыта и тд). этот компонент добавляет возможность в конфиге прописать все состояния и возможные переходы между ними, то есть из какого в какое можно перейти. то же самое будет полезно например для статусов заказов в магазине, приемка к публикации статьи.

также компонент позволяет вешать на смену статусов свои обработчики (через общий event manager). и добавляет в твиг удобные функции хелперы для проверки текущих статусов и возможности их смены. в статье например показан кейс - вывести кнопки для смены статусов у статьи, выводятся только те кнопки смены статусов, переход на которые разрешен в конфиге. раньше все это руками приходилось делать.

полистав пример тестового приложения понял что статусы хранятся в поле marking у сущности https://github.com/lyrixx/SFLive-Paris2016-Workflo...
поле имеет тип json_array. надо бы запустить этот тестовый проект, погонять. например для меня пока не очевидно как сделать фильтрацию сущностей по этому статусу, неужели отдельное поле/я добавлять и в подписчиках его менять.

также можно полистать исходники самого бандла, вот например метод для смены статуса https://github.com/symfony/workflow/blob/master/Wo...

Это типичный пример, когда люди не сами доходят до паттернов, а начитываются умных книг и суют свои репозитории и ддд без понятия зачем это нужно.
Сколько уже статей видел об использовании репозиториев в laravel, все прдлагают куегкт Model::all() и т.д. Плевать, что возвращают всё тот же Eloquent, который пытаются убрать.

В проектах на symfony даже при наличии doctrine творится такой же ад. То. что люди не умеют делать нормальные репозитории указывает на то, что оно им и не надо было такой абстракции. Для 99% проектов вообще не стоит тащить абстракции вроде репозиториев.

То что Вы пытаетесь реализовать, называется наследованием таблиц (Table Inheritance) - это такой способ эмулировать наследование классов в реляционных СУБД.

Всего существует несколько известных вариантов решения такой проблемы, например Single Table Inheritance и Class Table Inheritance (это если не учитывать нативную поддержку подобных вещей в некоторых СУБД, например PostgreSQL).

Полиморфные же связи (которые по-дефолту в Laravel) - это не очень хороший способ реализации, потому что не позволяет поддерживать целостность связей на уровне СУБД. Однако можно использовать и его, если Вам эта целостность не очень важна (ее надо будет поддерживать на уровне приложения).

К сожалению Eloquent не поддерживает ни Single Table Inheritance, ни Class Table Inheritance (зато их поддерживает Doctrine из Symfony), поэтому придется писать вручную.

Прежде чем это делать, я бы Вам посоветовал разобраться как Profile относится к User и OrgAdmin.
Является ли Profile подвидом пользователя (из названия честно говоря не понял), или же это просто набор дополнительных полей, которые можно оформить в виде связей?

Если и Profile и OrgAdmin - это подвиды (подтипы) пользователей со своим собственным набором полей, то Вам нужно добавить в общую таблицу отдельное поле type (это называется дискриминатор), в котором у Вас будет проставлен тип пользователя. Например 1 для User, 2 для Profile и 3 для OrgAdmin.
Короче очень похоже на стандартный Polymorphic Relationships из Laravel.

А потом переопределяете у модели User функции newFromBuilder() или newInstance() в которых Вы укажете какие классы моделей создавать для конкретного type. Вот например статья.

Дальше для Class Table Inheritance можно в трейт поместить функцию сохранения и родителя и потомка, потому что сохранять их придется вместе (на уровне БД), в зависимости от измененных свойств. Кроме того, нужно будет позаботиться об отображении (mapping) атрибутов родителя на потомков (__set и __get), на случай если вдруг захочется делать вот так (представьте что атрибут name принадлежит родителю - модели User):

$profile = new Profile();
$profile->name = 'John Doe';
$profile->save();

Короче это гемор в Laravel. Поэтому перед тем как делать, подумайте можно ли решить задачу проще - например через Single Table Inheritance, поместив все атрибуты в одну таблицу, либо делайте через стандартные полиморфные связи.

Когда я решал эту задачу, я все вышеуказанные функции помещал в трейты. Может когда-нибудь дойдут руки запилить отдельную библиотеку или отправить патч в само ядро фреймворка.

Погуглите по указанным ключевым словам (паттернам), может что уже появилось для Laravel.

По пунктам:

Почему в университете стало популярней разрабатывать сайты, ежели учить C++ и писать "толстые" клиенты.

Потому что скриптовые языки дают существенно бОльшую скорость разработки чем C++ что собственно является главным аргументом. Разработчики стоят дороже железа условно.
С++ остается в каких-то узко-специфических задачах со сложной математикой где производительности скриптовых языков не хватает. Писать на C++ интерфейс не актуально года с 2000 пожалуй что.

Когда произошла точка перелома, что "тонкие" клиенты теперь популярней и почему? Хотя ведь мобильные приложения, это ведь тоже "толстый" клиент

И мобильное приложение, и фронт сайта - могут быть и тонким и толстым клиентом, зависит от конкретного проекта.
Это всегда баланс между бизнес-хотелками и затратами.
Толстый клиент - лучше отзывчивость интерфейса, можно вынести часть нагрузки на железо клиента, дороже поддерживать (дорогие ios/android/angular/... разработчики, специфические проблемы синхронизации данных).
Тонкий клиент - все наоборот :)

UPD Если трактовать вопрос в стиле "почему веб более популярен чем десктоп":
1. Как показывает практика любой софт который физически крутится у пользователя можно взломать и получить бесплатно. Если софт не лежит на торентах - скорее всего он никому не нужен.
2. Многие сервисы сейчас продаются по модели ежемесячной-ежегодной подписки - это даёт существенно лучшие экономические показатели чем продажа платных обновлений.
3. Интернет становится все более доступным и по географии и по $, все более быстрым.

Все это делает модель SAAS и её наследников весьма привлекательным.
Я бы сказал так - сейчас нужны какие-то ОЧЕНЬ веские причины не использовать SAAS.

Скорее всего по тому, что Вы используете там т.н. колбэк-функцию (или по русски - функцию-замыкание), а область её видимости обычно строго ограничена.

Думаю, ситуацию исправило бы примерно следующее:

Mail::send('email_verify', $data, function($message) use ($user) { ...

Тут немного подробностей.

Из коробки очень даже гибко все получается.
Только от генератора Policy я отказался, и все валидации через контракт Gate в FormRequest в методе authorize.
Как-то так все получается.

// form request

<?php

namespace App\Http\Requests\User;

use App\Models\User;
use Illuminate\Contracts\Auth\Access\Gate;
use Illuminate\Foundation\Http\FormRequest;

class DestroyRequest extends FormRequest
{
    public function authorize(Gate $gate)
    {
        $id = $this->route()->getParameter('user');

        return $gate->authorize('destroy', User::query()->findOrFail($id));
    }

    public function rules()
    {
        return [

        ];
    }
}

// controller

<?php

namespace App\Http\Controllers\Api;

use App\Contracts\IUsersService;
use App\Http\Controllers\Controller;
use App\Http\Requests\User\DestroyRequest;
use App\Http\Requests\User\IndexRequest;

class UsersController extends Controller
{
    public function destroy(DestroyRequest $request, $id)
    {
        // do stuff
    }
}

// policy

<?php

namespace App\Policies;

use App\Models\User;
use Illuminate\Auth\Access\HandlesAuthorization;

class UserPolicy
{
    use HandlesAuthorization;

    public function index()
    {
        return true;
    }

    /**
     * rbac:user.destroy
     */
    public function destroy(User $user, User $entity)
    {
        if ($entity->hasRole(User::ROLE_ROOT)) {
            return false;
        }

        return $user->isEditor();
    }
}

Laravel - серверный фреймворк, который никак не работает с HTML. Тем более, в него не встроен Bootstrap.

Скорее всего вас сбивает с толку папка "bootstrap" в корне проекта. Формально, там хранится кэш ваших view, и сгенерированный autoload для запуска приложения. Точка входа, иными словами.

Все, что вам надо трогать в плане разработки - папки app, config, database, routes, и resources.
app - тут все ваши модели, контроллеры, эвенты, и т.д.
config - конфиги
database - миграции и сидеры
routes (5.3+) - файлы с роутами
resources - ваши представления (views)

Ну и папка public - точка входа (index.php), и .htaccess
Именно в эту папку вы можете складывать все html фреймворки, и попросту работать с ними.

Так же, вас могло спутать то, что при вызове метода artisan make:auth создаются представления, использующие bootstrap. Попросту перепишите шаблон этих представлений (resources/view/auth) под свои нужды.

Удачи в начале вашего пути.

Вам нормально ответили на вопрос и в тот раз. Если приложение сложное то есть смысл прятать запросы в репозитории а логику в сервисах что бы разгрузить контроллеры и уйти от дублирования кода.

Да и если оно очень сложное, может лучше Doctrine ORM? Там как раз таки поощряется использование Repository, Services.

Почитайте

вагрант это всего-то обёртка для настройки виртуалки, а так там обычная виртуалка, которую можно использовать в вируатбоксе как и любую другую. Просто возьмите образ и используйте его без вагранта.

Половину из списка можно сразу выкинуть. Например Kibana занимается визуализацией логов, а не сбором. В ELK стэке для этого служит Logstash. А Blackfire - инструмент для перфоманс-тестирования + метрики.

Дальше нужно определиться, где вы хотите разместить сервис. Если в облаке, то New Relic, Loggly и Logentries остаются в списке (если ваш сервис на AWS, то добавляется CloudWatch), но из него уходят LogStash и GrayLog2. Но если хотите держать сервис у себя, ваш дальнейший выбор только между LogStash и GrayLog2.
В первом случае у вас продолжение поисков -- на следующем этапе уже встает вопрос цены продукта.

=====
"Так же интересно чтобы можно было собирать логи ошибок nginx/mysql/postgres, не требовало особых плясок с бубном"

Все три сервиса написаны на C-lang. Это значит, что, в отличии от Java, они не будут выкидывать ужасные стэктрейсы на 100500 строк, а всегда будут укладываться в 1024 символа. Именно этот предел есть у стандартного syslog. Поэтому пусть они и дальше пишут в syslog, а уже в нем вы настроете куда редиректить логи дальше. Таким образом вам не надо будет при смене сервиса сбора логов бегать по всем нджинкасам и постгрессам и менять настройки - достаточно будет поменять в одном месте, в syslog.
Но! Если будет Java приложение, то такое не пройдет и вам потребуется что-то типа GELF, чтобы успешно доставить полный размер exception.

https://github.com/LaravelRUS/docs
Но пока переведено очень мало, так что читайте laravel.su/docs/5.2, отличий не так уж много.

Надо прописать путь к классу

"autoload": {
        "classmap": [
            "vendor/serj1chen/way-for-pay-sdk-php/WayForPay.php"
        ]
    },