DevMan

Смешались в кучу кони, люди...
Давайте по порядку.

Должен ли UX/UI дизайнер знать компоненты таких фреймворков как React и Vue

Если команда разработчиков заранее знает, что будут использовать какой-нибудь набор готовых компонентов для работы (Vuetify, Material UI, etc), то дизайнер должен их знать и использовать как основу, дабы не плодить лишних сущностей, так как без боли эти компоненты можно разве что перекрашивать.

подготавливать макет прямо на React, но без логики

"Макет на React без логики" - это вёрстка.
И боже упаси, чтобы это делал дизайнер - с этим и большинство фронтов так себе справляется (во многом потому, что через 3 месяца работы над пет-проектом говорят "я уже хорошо знаю HTML и CSS, пошёл учить Реакт и получать ЗП в 200+", ха-ха).

не зная можно ли вообще реализовать такой календарь

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

но наверное какие-то основы, работу с NPM, CSS/SASS препроцессоры он должен знать?

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

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

Вообще такое ощущение, что все вокруг просто на самом деле ничего толково делать не умеют, но пытаются себе цену добавить мнимым знанием кучи всего. Сфокусируйтесь на одном чём-нибудь.
Человеку, который делает гениальный дизайн, прощают всё - сложный характер, срывы сроков, никакую структуру файлов, Layer1-layer2 - и возвращаются к нему снова, потому что это профессионал в своём деле, и нет совершенно никакой нужды добавлять себе стоимость второстепенными навыками. Разве что самому интересно..

File | Settings | Editor | General | Editor Tabs -> Open new tabs at the end

Нет, не существует. Поэтому модераторы карают за нарушение правила 3.1, когда пользователи на свой вопрос лепят какие попало теги.

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

Editor → Color Scheme → Language Defaults → Inline parameter hints

Курсы. По хакингу. Для новичков.


Это абсолютно несовместимое сочетание слов!

Почитайте этот ответ и комментарии к нему. И этот ещё полезно будет.

Господи, опять очередные страдания, "люди добрые памажите решить чем мне заниматься, мы сами не местные пять семей по вокзалам". У вас у всех прямо гамлетовские страдания, "быть или не быть". Вопрос века, ошибка смерти подобна - "в какой области я больше бабла получу???!!!111" Да ни в какой. Никому ты не нужен, такой беспомощный нытик. Ни в вебе, ни в энтерпрайзе.

В любой области ценятся самостоятельные разработчики, те, которым можно поставить задачу, и они сами исследуют проблему, разработают решение и будут его внедрять. А не те, которым надо всё разжевать и в рот положить. А потом еще проверять за ними, все ли сделано правильно.
Если ты не можешь самостоятельно решить несложную организационную задачу - промониторить вакансии, походить по собеседованиям, составить собственную картину и принять самостоятельное решение, то как разработчик ты тоже полный ноль и неважно, 1 год ты тему изучал, или 20.

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

НИ В КАКОЙ. В прошлом веке кончились те времена, когда ты выбирал себе профессию на всю жизнь. Сейчас мир меняется если не за 2 года, то за 10 лет неузнаваемо. Важны способности, а не навыки. Важно понимать общие принципы построения программных систем, а не конкретный синтаксис одного языка. Да, возможно через 5 лет разработчики БД будут совсем не нужны (на самом деле нет). Но я тебе точно говорю что и через 5, и через 50 лет будут нарасхват люди с мозгами и руками. И надо не затачивать свои руки под один конкретный инструмент, а разивать мозги, учить теорию, учиться самостоятельности, пытаться стать исследователем, а не мелким лавочником.

Мое решение (работеает уже давно). Работает на всем, что шевелится - Андроиды, Windows, Макинтоши.
SSH тоннель с ключами, защищенными пасскодами.

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

На машине клиента (домашней):
нужен батник из одной строчки, программа plink.exe и закрытая часть ключа.

plink -P ПОРТ -l ЛОГИН -i КЛЮЧ_ЗАКРЫТЫЙ.PPH  -N -L 23389:МАШИНА_КЛИЕНТА_В_ОФИСЕ:3389 АДРЕС_ШЛЮЗА_В_ИНЕТЕ
pause

Клиент у себя врубает батник, вводит пасскод от ключа и подключается на адрес типа 127.0.0.1:23389, а SSH его уже туннелит куда надо.

Есть процедуры, позволяющие сгенерить ключи без визита сотрудников в офис.

Ну, так поместите все в одну форму. Только дайте имена своим инпутам.

<form class="quize-form-our">
   <label><input name='opa[]' value="Один" type="checkbox">Один</label>
   <label><input name='opa[]' value="Два" type="checkbox">Два</label>
   <label><input name='opa[]' value="Три"   type="checkbox">Три</label>

 <label><input name="opa2" value="Один" type="radio">Один</label>
   <label><input name="opa2"  value="Два" type="radio">Два</label>
   <label><input name="opa2" value="Три"  type="radio">Три</label>

</form>

$result = preg_replace('/\W+/u', '', $string)

Добрый день.
Нюанс 1. Насколько защищен провайдер.
Насколько защищен провайдер. Существует несколько типов защиты:
- Защита от BPDU пакетов. Вариант 1. BPDU Guard (отключить порт, при любом BPDU пакете входящего с вашего порта).
- Защита от BPDU пакетов. Вариант 2. BPDU Filter (игнорировать любые BPDU пакеты).
- Защита по количеству MAC адресов с вашего порта: Вариант 1. Разрешить только первый MAC адрес. Остальные игнорировать.
- Защита по количеству MAC адресов с вашего порта: Вариант 2. При превышении количества MAC адресов блокировать Ваш порт.
- Защита от атаки на DHCP сервер - сколько запросов можно посылать на DHCP сервер с Вашего порта. (DHCP snooping)
- У Билайн авторизация построена интересно. Твое устройство авторизуется на WEB портале, после твою сеть добавляют в другой VLAN и ты получаешь IP адрес по DHCP. Аналог 802.1x авторизации, когда разрешенные MAC в одном VLAN, а запрещенные в другом VLAN.
- Провайдеры любят делать финт, что после запроса адреса на DHCP сервере, только этот MAC адрес получает доступ в интернет и ответ на DHCP. У других устройств ответа по DHCP нет.

Есть очень большая вероятность, что у вашего провайдера включена защита либо 802.1x либо DHPC Snooping

Востребованы меньше, но зарплаты выше и условия лучше. Мало используют по нескольким причинам. Прежде всего из-за замкнутого круга: Для мало используемых языков мало программистов, а те языки, на которых мало программистов, мало используют. Но он постепенно "растягивается" и вполне может совсем разорваться через 5-10 лет. Кроме того, функциональный код выразителен и хорошо распараллеливается, но для многих компаний это не является значимыми достоинствами, а вот низкая скорость компиляции и высокое потребление ресурсов являются значимыми недостатками. Тем не менее, рекомендую выделить на ФП часть своих сил и времени. Как минимум это улучшит ваш алгоритмический аппарат. Как максимум даст полезную подготовку для будущего рынка труда. В конце концов, ООП тоже не сразу стал популярен.

Не надо писать свой движок. К нему не будет документации, его не проверяет сообщество, баги в нем будут всегда, и хорошо, если будут тесты. Достаточно гибким это решение тоже не будет. Поддерживать и сопровождать такие проекты потом невозможно. Чтобы на голом PHP написать проект с нуля и нормально, требуется колоссальный опыт и отличное знание шаблонов проектирования. Тем более, что все равно в проект вы будете подтягивать различные удобные библиотеки, которые и так используются в известных фреймворках. Например, Doctrine.

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

Я не говорю, что обязательно нужно использовать таких монстров как Laravel и Symfony для создания API, но микрофреймворк Slim вполне неплох. Насчет "у микрофреймворков также версии быстро меняются" не могу ничего сказать, по крайней мере, код с 3 версии Слима на 4 переносится без проблем. Ведь в том и суть микрофреймворка, что там кода, зависящего от него, почти и нет - вся ваша бизнес-логика независимая.