O Di

https://www.nginx.com/blog/nginx-websockets-perfor...
Я бы оставил nginx перед нодой.
+ на nginx можно переложить ssl

Прошло какое-то время, решил ответить на свой же вопрос.
Отслужил в армии (конечно же, сидя за ПК, да читая книги по сетям, мечтая о гражданке).
По приходу 2 месяца убивался без работы, пытаясь поехать в Москву, но не хватило меня - слишком далеко ездить и затратно, когда на дорогу нет денег.
Мониторил сайты с работой около дома, тыкался во все айти и около того вакансии. Ответили на одну - "Опытный Linux-админ", предложили собеседование. Я его, конечно же, не прошел. Тем не менее, компания внедряла Asterisk, о котором я слышал краем уха, и проводила по нему курсы официально в согласовании с Digium. И мне предложили их пройти бесплатно, отработав взамен тоже время курсов (неделю 5\2).
Я прокачался в IP-телефонии, Linux, виртуализации, переводу технических статей с английского :) По итогу предложили работу, результатом был готовый лог-сервер из связки ELK + изучение и завертывание всё в Ansible. Изучалось всё с нуля и методом гуглежа и вышло очень успешно.
Потом пришлось уйти на производство рядом с домом, где оказалась цела корпорация у меня под носом, о которой я и не знал. Сеть - в плачевном состоянии. Тут оттачивались навыки закупок оборудования, организации сети, прокладка и монтаж СКС, общение с поставщиками, пресловутый, но нужный 1С и сервер под него. Тут же и знания по Asterisk пригодились очень сильно. И это всего за пол года после армии.

Если кто наткнется на мой ответ с такой же ситуацией - никогда не отчаивайтесь и ищите все возможные пути. всё получится.

1) jquery и vue.js совершенно разные вещи и решают они совершенно разные задачи. jquery создан для кросcбраузерной работы с DOM. Vue.js и подобные созданы для работы с данными.

2) Не факт. Для создания модальных окон, лайтбоксов, слайдеров, вам может понадобиться там и jquery, т.к. аналоги jquery плагинов не всегда есть на нативном javascript. + Готовых компонентов для vue.js не так уж и много, по сравнению с react или angular. Но их кол-во растёт

3) А что вам даёт jquery, кроме добавления нескольких плагинов? По сути, ничего такого vue вам не даст.

4) Очень многое. Разделение всего и вся на компоненты. Которые можно переиспользовать в разных частях сайта не думая о дублировании стилей, js логики и т.п.

5) Да во всех можно использовать, будь то блог или интернет магазин.

6) Если проект с нуля, то можно использовать vue.js. НО!!! Для начала, вам, его нужно изучить и достаточно хорошо!!! А так же, скооперироваться со своей командой. Дизайнерами и серверными разработчиками.

7) Лично я, пока не знаю его на достаточно хорошем уровне, но уже могу легко написать на нём блог и прикрутить node.js + express + mongodb для обработки данных на сервере. Бесконечная подгрузка постов, фильтрация данных без перезагрузки и триллион всего.

Гуглите на youtube видосы по vue.js, лично вам, на русском, что бы понять, что это такое и для чего вообще используют подобные фреймворки. Изучите хорошенько javascript иначе не сможете писать на этом фреймворке.

Я проходил курс тут. Он на английском, но достаточно понятный.

P.S. jQuery можно использовать вместе с vue.js без всяких проблем

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

Будьте конкретны:
- "Моя цель на ближайшие 6 месяцев - вырасти до позиции XXX в текущей компании". И далее:
- "Что мне нужно сделать для того, чтобы в течение 6 месяцев в моей компании вырасти до XXX ?"

С этим уже можно обратиться к людям, обладающим достаточной компетенцией в помощи вам с ответом на этот вопрос: "Для того, чтобы в нашей компании стать XXX, нужно знать ЭТО и уметь ТО".

- "Что мне нужно для того, чтобы узнать ЭТО и научиться делать ТО ?". Cоставляете план действий (разбиваете необходимые шаги на месяцы, недели, дни) с дежурными сроками (для проверки запланированного и достигнутого, внесения в связи с этим необходимых корректировок и т.п.) - и вперед.

Но все начинается с конкретики:
- "...хочется максимально эффективно развивать себя...". Что конкретно значит (для вас) "максимально эффективно"? По каким критериям вы будете определять, эффективно вы развиваетесь или нет? Количество прочитанных книг? Сложность решаемых задач? Что конкретно?
- "...чтобы стать не только полноценным девом...". Что конкретно значит (для вас) "полноценный дев"? Как вы поймете, что стали "полноценным девом"? Вы добьетесь определенной должности? Будете зарабатывать определенную сумму денег? Что конкретно?

Успехов.

теория и практика. и так по кругу.
только чтение ничего не даст.

прочитали паттерн -> посмотрели диаграммы -> тут же сели и попробовали реализовать самостоятельно, а не переписывая с книги/инторнетов -> посмотрели готовые реализации -> сделали выводы -> взялись за следующий.

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

Здесь стоит посмотреть с 2х строн:
1. Если вы часть команды и мелкая сошка -- смирится, либо идти по головам к начальству с наглядными примерами, и объяснением того в долгосрочной перспективе ваш подход принесет больше прибыли (меньше убытков). Если начальник адекватный, он задумается и поставит вас тимлидом, если нет -- то это его проблемы, вы свою точку зрения донесли.

2. Если вы лицо принимающее решение в команде, и являетесь тимлидом --- тогда руководить и вводить метрики, ревью кода, и т.п. штуки, чтобы когда кто-то косячил, другие говорили ему "Вася ты дурак".

Мы стараемся не запускать эту проблему посредством code review, пытаясь распределить нагрузку по ревью между наиболее опытными участниками. Если в коде есть проблемы - тикет возвращается на доработку с замечаниями. Даже если банально не мержится с главной веткой. Попробуйте наладить этот процесс.

Также мы всё собираемся настроить Continuous Integration. Jenkins может прогонять по коду проверку на соблюдение стандартов и покрытие тестами, а затем показывать результаты в красивом виде. Если чей-то коммит показывает более чем N ошибок в расчёте на единицу объёма кода - можно возвращать на исправление.

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

Ещё пара идей.

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

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

Ну и важно, чтобы у самих разработчиков была установка на хороший код, профессиональная гордость. У фрилансеров её, бывает, нет, а есть отношение "тяп-ляп, лишь бы работало и лишь бы часы оплатили, а там хоть потоп". Учитывая, что их заказчики занимаются code review нечасто, развитие такого отношения закономерно. Но всё-таки хочется писать красивые программы. Такое желание обязано быть.

Я, конечно, сам не волшебник, я только учусь, и работа с командой - такая штука, которой надо постоянно учиться. Видимо, вы тоже учитесь; успехов в этом.