Максим Федоров

Для слов. фраз хорошо идёт lingualeo
Для грамматики duolingo

Нет, строка должна хранить текст. А для списка фиксированных значений есть Enum

без разницы

Поскольку меня сюда призвали, то напишу пару слов.

Если вы ещё не доросли до отдельной железки под базу - то для базы не будет принципиальной разницы какой гипервизор у вашей виртуалки. Интереснее вопрос насколько честен хостер (уточняйте отдельно, я с хостерами не знаком).
openvz заметно легче для хостера по ресурсам и позволяет легко продавать ресурсов сильно больше чем у него есть в действительности.
С kvm - сложнее заниматься оверселлом хотя бы по памяти, хотя помнится даже там можно.

С openvz у вас будет на порядок меньше возможностей настройки, т.к. ядро используется хост-системы и никто не даст вам его трогать. И весьма старое ядро, кстати.
На kvm соответственно полноценная виртуальная система. Можете ставить что угодно и как угодно тюнить ядро. Если хостер уважает себя и предоставляет virtio устройства - то это и работать будет внятно.
mysql запустится и там и там. Краеугольный для любой СУБД вопрос производительности дисков и там и там от вас полностью скрыт и зависит от хостера.

Универсального ответа нет. Если вы под базу не настраиваете ядро, то возможно и openvz подойдёт, обычно там предлагают больше ресурсов за те же деньги.

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

Файлы базы нормально нагруженной СУБД в виртуалку засовывать особого смысла нет.

Если же неудобства и оверхед по I/O вас не волнуют - без разницы, контейнер это будет или виртуальная машина, важнее на каких дисках это всё будет располагаться и верно ли будет настроена сама СУБД в плане производительности.

Смотрите, например, отличный ответ Melkij - Как настроить Postgres в Docker?

P.S. - добавьте mysql в тэги, кстати. Всё сказанное выше справедливо и для него, хоть и написано про постгрес.

Если быть более, конкретным, зачем нужна эта опция, при генерации модели через Gii?

Чтобы вы могли добавить свои кастомные методы или переопределить родные (all(), one() и другие, короче переопределить родной ActiveQuery и изменить на свои абстракции)

Вот пример контроллера:
actual() -- такого метода нет в ORM, а мне нужен, ну вот хочу так пользоваться:
$trainings = Training::find()->actual($date);

Может:
1. 01.01.201 - валидная дата за 201 год
2. timestamp за такой год просто не существует, минимум 1970

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

interface HasStatus
{
    public const STATUS_NOT_PAID = 0;
    public const STATUS_PAID     = 1;
    public const STATUS_CANCEL   = 3;

    public function getStatus(): int;
}

class StatusHelper
{
    /**
     * Статистический метод получения списка статусов
     *
     * @return array
     */
    public static function getStatusList()
    {
        return [
            HasStatus::STATUS_NOT_PAID => 'Не оплачено',
            HasStatus::STATUS_PAID     => 'Оплачено',
            HasStatus::STATUS_CANCEL   => 'Отменена',
        ];
    }

    public function getStatusName(HasStatus $entity): string
    {
        ArrayHelper::getValue(self::getStatusList(), $entity->getStatus());
    }
}

Соответственно все ваши модельки должны имплементирвать интерфейс HasStatus. Таким образом вся бизнес логика находится в одном месте и отвязана от БД

Илья, ты не перейдешь от фотошопа полностью. Делать нужно так:

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

2) Растровые коллажи рисуем конечно в фотошопе, экспортируем в фигму, как PNG или JPEG

3) Фигма - для сборки, потомучто а) гораздо быстрее работа с макетами б) гораздо меньше весят файлы в) несколько человек могут дизайнить одновременно г) можно делать компоненты - кирпичи, например ты нарисовал кнопку и сделал её компонентом, затем можешь её плодить одним нажатием кнопки, так, ты можешь сделать хоть 100 таких кирпичиков и за считанные минуты собрать интерфейс (посмотри такого чувака, как Roman Kamushken, чтобы понять насколько это ускоряет работу)

НО, можно делать весь дизайн только в фигме, не проблема, просто учти, что сложные фигуры, 3д, коллажи и так далее в ней покачто ты не сделаешь.

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

ролики на ютубе есть, но их объясняют такие болваны с ээээканьем мммммэканьем, что сил нет смотреть 15 мин то, что можно обьяснить за 10 сек.

из адекватного, русское:

знакомство с фигмой
почитать статейка старая, много что поменялось, но визуально там показаны преимущества
полезный материал по резине

3. Развиваться в самом бекенде - php

Какой смысл распыляться на разные штуки если вы еще тут толком ничего не сделали.
Тем более что есть возможность заниматься чисто бекендом судя по всему. Это хорошая возможность ващет.

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

Если хочется изучать, изучайте в свободное время что угодно, но цель стать фуллстаком это так себе вариант.

Конечно же написанное всё имхо)