Алексей Уколов

что я делаю не так?

Используете древнюю библиотеку на современной версии php. Или ищите замену, или ставьте php 5.

# Save the DB to disk.
#
# save [ ...]
#
# Redis will save the DB if the given number of seconds elapsed and it
# surpassed the given number of write operations against the DB.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# save ""
#
# Unless specified otherwise, by default Redis will save the DB:
# * After 3600 seconds (an hour) if at least 1 change was performed
# * After 300 seconds (5 minutes) if at least 100 changes were performed
# * After 60 seconds if at least 10000 changes were performed
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 10000

https://redis.io/docs/latest/operate/oss_and_stack...

У PHP разные файлы настроек для разных сред. Вы поменяли настройки для CLI (консоли), а нужно для FPM (скорее всего).
Вы вывели вот phpinfo() — там указан файл, из которого берутся эти настройки. Поищите по странице «.ini» и увидите, где менять.

1. Текст прекрасно центрируется по горизонтали. Если вам нужно центрировать его ещё и по вертикали, то есть располагать по центру изображения, то для этого нужно написать хоть какой-то код. У вас указан только text-align, он работает, странно ожидать чего-то большего.

2. Укажите желаемый цвет фона в .items.

«Некоторую информацию» нужно хранить в стейте или менеджерах, «работать с DOM» нужно средствами Реакта, а для истории использовать соответствующие библиотеки. И вот от класса ничего не осталось, можно его удалить.

Положите ассеты на Гитхаб и подключайте оттуда.

Такие файлы кладут вне директории, которую обслуживает веб-сервер. Примерно так:

./db.php
./public/index.php

В db.php вы подключаетесь, реквизиты храните в нём же или в .env-файле рядом (или ещё как-то), а в настройках веб-сервера в качестве корневой директории указана public. Тогда через него невозможно будет обратиться к "секретному" файлу.
(есть ещё всякие уязвимости, которые делают такую защиту всё же не стопроцентной, но они далеко за рамками данного вопроса).

Проблемы, естественно, есть, поскольку есть уязвимости.
Столкнётесь ли лично вы с ними никто не знает.

Скорее всего, вы пытаетесь работать с объектом до того, как получен ответ от сервера. Почитайте про асинхронность в js, это фундамент.
Второй вариант — у вас иная структура ответа. Например, приведённый объект вложен в какой-то другой.

Если в компании нормально кадровый процесс построен и нет требования «познакомиться лично», то не нужно. Документы либо электронно подписываются, либо пересылаются почтой.

Ну, скроете вы его, а дальше HR либо на этапе первичного разговора, либо уже на собеседовании спросит всё равно. Надеяться, что удастся убедить при живом общении можно, но, учитывая огромный пул одинаковых кандидатов, шансы невелики. Поэтому я бы советовал быть максимально прозрачным и написать какой-то сопроводительный текст, объясняющий ситуацию. Тогда на собеседование вас позовут люди, которых ваша учёба не пугает по каким-то причинам — сэкономите время и себе, и другим.
Само по себе отсутствие диплома почти никого не отпугнёт, а вот дополнительная занятость вполне может. Если даже вы успешно такими манёврами куда-то пробьётесь, есть шансы быстро вылететь, когда люди поймут, что получили не то, на что рассчитывали, и придётся уже это объяснять на следующих собеседованиях.

Попробуем отделить коней от людей, насколько это получится.
Говоря просто: API - для отдачи непосредственного среза данных, обычно в виде JSON, WEB - для отдачи целых страниц в виде HTML.

Всегда думал что api.php нужно для запроса от сторонних приложений, сайтов к твоему сайту для получения какой то информации, которую я хочу предоставить, без авторизации.

Ну, неправильно думали, ничего страшного. Точнее, очень узко. Вот есть у вас сайт, а потом вы решили сделать к нему в пару мобильное приложение. Оно стороннее? Ничего сделать с отданным через WEB HTML оно не сможет*, потребуется API.
Наличие или отсутствие авторизации тут совершенно ни при чём.

в тоже время используя api.php любой человек может запросить любой роут и получить кучу информации

Любой человек получит то, что вы ему отдадите. Никакого запрета (или сложностей) на внедрение авторизации в API нет.

Количество Middleware на web.php значительно больше, т.е. любой запрос проходит больше проверок перед тем как выдать результат.

Middleware - это любые обработчики, а не только проверки. Т.е. "больше обработчиков не значит больше проверок". Любые обработчики вы можете навесить и на API**. И их даже не надо писать отдельно, в Laravel уже всё есть.

В итоге вопрос, с точки зрения безопасности, производительности есть преимущества api.php перед web.php

С точки зрения безопасности разницы нет. API может быть несколько производительнее за счёт того, что обрабатывает и отдаёт меньше "лишнего". Но по этим аспектам их вообще не надо сравнивать, это всё равно, что выбирать между экскаватором и самосвалом по степени лёгкости угона того или другого.

* без костылей
** с поправкой на отсутствие сессии обычно

Со степенями в Питоне всё прекрасно. Просто запись -10**2 эквивалента записи 10**2 * -1, а не (-10)**2. Переменная как раз как бы добавляет эти скобки вокруг значения.

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

"Думал" - это такая же часть реализации, как и "писал", так что выделять отдельно её нет никакого смысла.

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

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

В чём вообще сложность-то?

div {
    width: 0px;
    height: 0px;
    padding: 0;
    border: none;
}

div:after {
    content: '';
    position: absolute;
    width: 0px;
    height: 0px;
    border-top: 200px solid transparent;
    border-bottom: 200px solid transparent;
    border-right: 360px solid #00FF00;
}

смещение сделано, чтобы убедиться, что всё на месте; без него совпадение 100%

и вперёд!

Да.
Выдумывать какие-то дополнительные шаги до того, как вы откроете документацию и попробуете по ней написать hello world — это просто прокрастинация. Спустя несколько минут вы уже самостоятельно поймёте, где у вас проблемы возникают.

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