Alex

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

А если отвечать буквально по вашему вопросу, посадите на пин 3.3В подходящий транзистор, базу его подключите к управляющему пину. А уже к транзистору ваш диод. Но, раз у вас нет резисторов, скорее всего транзистора тоже не найдется. А во вторых, транзистор тоже надо защитить резистором.
Поэтому, раздобудьте резисторов.

Конечно же можно! Главное чтобы об этом говорилось в названии и цена была более 100к, а ещё чтоб гарантировали обучить за неделю. Тогда это гарантированно рабочий курс, который поможет стать сеньором)))

Но ведь новизна это же не плохо?
В 16" макбуке проц 9го поколения, быстрый SSD, хорошее охлаждение по сравнению с другими макбуками. Наконец то GPU тянет все что угодно, хочешь поиграть - играй, не хочешь - не играй. Раньше было только хочешь поиграть - страдай) Но лично мне нравится что лаунчпад не лагает на нем)))
Старые макбуки 15" - проблемная клавиатура и флексгейт на более ранних версиях, радости мало...

Проксируем апачем приложение node, или удаляем апач. но лучше nginx'ом проксируй

По описанию вы вообще ничего не сделали. Не подключили шапку/подвал, не сделали контент динамический, даже линки не вывели. А просто закинули вёрстку в тему вп. Тут в 2 словах не объяснять, вообще нужно хоть базово понимать пхп. А вообще ютуб в помощь там уроков аргон и маленькая тележка.

как обычно, ответ на такие вопросы - то что вы и ваша команда лучше знает, то и использовать

а так желательно symfony, в symfony есть skeleton микросервиса. Лучше его, так как там соблюдаются и поддерживаются мировые стандарты кода

Сила воли.

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

Сейчас умею html, css, sass, pug, gulp, bootstrap, немного php и основы JS (а также jquery), ну и само собой WordPress

Меня в своё время с такими знаниями(в далекие бородатые 2012) даже на порог конторы не пустили, когда начали спрашивать "основы js", которые я не знал. А вы 8 лет стагнируете и топчитесь в знаниям, которые по сути охватывают первый год "учебы", что делали остальные 7 лет?)

среднем выходит $800-$1000 в месяц при плотном графике

Т.е за 8 лет вы на сайтах выросли до 1000$ в месяц? У Вас проблемы)

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

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

удаленке джуниор фронтенд разработчика

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

Вопрос 1
Браузер инициирует новое tcp соединение на тот же 80 порт сервера или бывают случаи что на другой ?

WebSocket работает не поверх голого tcp, а поверх http (а тот уже поверх tcp или tls -> tcp). 80 порт стандартный для http, а 443 - для https (http поверх tls). WebSocket по умолчанию использует те же 80 и 443 порты для ws и wss протоколов соответственно. Но никто не мешает использовать кастомный порт. Конкретные порты для конкретных протоколов - это не более соглашения. Порты работают на IP уровне, который ничего не знает о прикладном уровне.

Вопрос 2
Что сервер делает с ws пакетами - проксирует их к СП как есть в обертке, или же обертку раскрывает и передает "чистые/сырые" данные далее ?

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

Вопрос 3
Как сервер отличает ws от http - по некой сигнатуре - типа по последовательности первых пришедших байт, по которым можно распознать что это именно ws а не http ?

По http заголовкам. В частности клиент шлет заголовок upgrade в котором говорит, что хочет WebSocket и еще несколько специфичных для WebSocket заголовков, а сервер отвечает статусом 101 и своим набором заголовков. Это и есть WebSocket рукопожатие. Само общение происходит уже в теле запроса и теле ответа.

Вопрос 4
Как эти данные передаются в сторону СП - через переменные окружения, или через unix-socket или через tcp стек?
Если используя последние два варианта, то получается что сервер держит внутри системы соединения с СП до тех пор пока "наружное" tcp соединение между клиентом и сервером не буде закрыто?

На уровне tcp вообще пофиг сколько времени открыто соединение, какая из сторон в какой последовательности и сколько данных отправляет. Тут лишь то, что клиент может попробовать открыть соединение, сервер его может принять (или отклонить), а после любая из сторон может слать данные другой или закрыть соединение. Ну и плюс есть гарантии, что потерянные данные будут отправлены повторно и порядок получения совпадет с порядком отправки. На уровне http у нас обычный запрос-ответ, просто клиент слишком долго шлет тело запроса, а сервер - тело ответа. На уровне WebSocket у нас в обе стороны ходят MessageFrame'ы, содержащие данные + метаданные и имеющие четкие границы.

Вопрос 5
В свою очередь СП это отдельный unix процесс отличный от основного бекенд приложения, которое работает по принципу "спросили - запустился - обработал - сформировал ответ - отправил - завершился" Или же это все то же бекенд приложение только в том случае если с ним установлено ws-соединение, оно не прекращает свою работу?

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

P.S. если обе стороны (и клиент и сервер) не ограничены только http протоколом для общения через tcp (как например это происходит у браузерных приложений), то WebSocket будет лишней нагрузкой как на сеть, так и на вычисления. Лучше взять какой-нибудь бинарный сериализатор, с четкими границами (msgpack, flatbuffer) и гонять данные по raw tcp или tls.

А почему, собственно, вы эту задачу хотите с помощью постгреса решать, а не с помощью намного более подходящих решений на базе инвертированных индексов - Lucene, Elasticsearch и т. д.?