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

Ну, скроете вы его, а дальше 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 — это просто прокрастинация. Спустя несколько минут вы уже самостоятельно поймёте, где у вас проблемы возникают.

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

А ведь и правда есть термин для них (но не тип, конечно): Well-Known Intrinsic Objects

Если же вы спрашиваете как затипизировать что-то, что может быть "RegExp, Array, Function и другим" (и не указывая при этом каждый тип явно), то должен, наверное, подойти только object (не смог в доке TS найти отличается ли TS-тип object от базового JS-объекта; например, в TS есть явная типизация функций, но можно ли её заменить на object?). Но это максимально странная задача, которую явно надо решить каким-то другим способом.

document.documentElement.classList.toggle('foo', document.querySelector('li.selected'))

The overflow CSS shorthand property sets the desired behavior when content does not fit in the element's padding box (overflows) in the horizontal and/or vertical direction.

• visible
  Overflow content is not clipped and may be visible outside the element's padding box. The element box is not a scroll container. This is the default value of the overflow property.

https://developer.mozilla.org/en-US/docs/Web/CSS/o...

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

Чтобы можно было подключить к проекту "внешний" реверс-прокси, который имеет доступ только к контейнеру nginx. В документации есть примеры для Varnish и Traefik.

Сейчас это работает через команду CURL. Но как это преобразовать в HTTP-зарос?

Это и есть HTTP-запрос.

Так, чтобы я мог его ввести просто в адресной строке браузера.

Если сервер это не поддерживает, то никак. Если поддерживает (то есть принимает параметры из URL, а не только из тела запроса), то нужно сформировать query string.

Иначе смысл от этих компонентов если можно их добавить после новой идеи.

Сначала нужно сделать просто и понятно. Потом, при необходимости, уже усложнять. Заранее усложнять себе жизнь совершенно ни к чему.

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

А вот если мы скажем, что это компонент SettingsControl, например, у которого есть title и children (а в них может быть что угодно), то сможем переиспользовать блок для всех остальных настроек. Но, может, этот дизайн используется не только в настройках, а вообще по всему проекту - тогда разделение и именование будет уже другим.
Сам контрол тоже можно обобщить до RadioInputWithImages - тогда, если у вас в каком-то другом месте будет похожий контрол выбора котят, а не темы приложения, вы просто поменяете контент, а логика и вёрстка будут переиспользованы.

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

Никак.

Чтобы сделать эту порнографию, нужно прочитать первые 10 страниц любого учебника javascript.

- return item[index] >= 25
+ return item[1] >= 25 && item[2] === true

Вы указываете хост clickhouse-learn, но этот хост зарегистрирован только внутри сети internal_clickhouse_net. На хостовой машине такого адреса не зарегистрировано, вот и не получается достучаться.
Но вы прокидываете на хостовую машину порт CLICKHOUSE_PORT - то есть обращение по адресу 127.0.0.1:CLICKHOUSE_PORT будет работать.

TLDR: Поменяйте в конфиге подключения хост на 127.0.0.1.

В Setup вы присваиваете gameOverStatus ноль, а потом в while проверяете его на равность единице (в комментарии пишете при этом противоположное).
Естественно, 0 != 1, цикл не запускается и программа заканчивает исполнение.