Михаил Р.

Плохо писать текст в элемент через innerHTML.
Второй вариант короче (на одну строку), и подходит тогда, когда потом нужно снова использовать element. Мне кажется, он предпочтительнее.
UPD: ой, я и не заметил (читая вопрос через смартфон), что в первом коде используется два раза равенство. Такой код работать будет, но он не явный, а неявные штуки - зло. Новичков он может поставить в ступор, т.к. не сразу ясно, что будет содержаться в переменной. И этот код также похож на опечатку, типа вероятно нужно было использовать сравнение (в данном случае, по названию переменной все понятно, но все же).

снг-бодишопов перфоманс ревью опен-сорс

Лец ми спик фром май харт.

По теме:
1). Каким образом вы сделали данные выводы? Вы описываете исключительно свои частные субъективные наблюдения или у вас есть какие-нибудь источники, может, HR-handbook, где прямо описывается практика вешания ярлыков? Не сочтите за какую-то грубость, просто так можно что угодно утверждать.

2). Вопросы, которые вы перечислили, вполне нормальные, мне на каждом интервью их задавали. Так проверяется мотивация, любовь к своему делу, уровень развития собеседника.

3). Развиваться на и вне работы - рядовое качество нормального айтишника. Если кто-то говорит, что уже достиг каких-то высот и дальше ему развиваться некуда, то этот человек либо лжёт, либо скоро устареет и потеряет ценность. Область IT меняется постоянно и относительно быстро и изучать что-то самому - суровая необходимость, ибо на ряд специальностей нет образовательных программ даже на Западе.

Вас взломали и у вас нет квалификации в расследовании взлома?
Делаем образ выключенной системы снаружи и бекапим его себе (зачем? Возможно найдете того кто сможет расследовать)
Берем список софта и убираем из него все, что не требуется для работы сервиса
- пхпмайадмин, фтп, как раз примеры такого софта

Сносим ОС (считайте что скомпроментирован рут и все тулзы ОС)
И ставим по хорошему мануалу с изрядной долей паранои (чаще всего одна статья не поможет - делайте свои заметки при установке)
Максимально изолируем все от всего
Наружу смотрит только вебсервер
ссш по портпиннингу (оно делается в полпинка, как на стороне клиента так и на стороне сервера)
Ваши цмс и скрипты должны обновляться регулярно
Следите за логами - часто взлом происходит в течении нескольких дней и простой греп по логам покажет, кого вам нужно забанить по ип и где поставить капчу

То что у вас есть бекапы делает вашу ситуацию в разы лучше

let result = array.reduce((acc, elem) => (elem > 0) ? acc + elem : acc, 0)

В общем добавьте стартовое значение аккумулятора = 0 перед закрывающей скобкой редьюса

const array = [-1, 0, 1, -5, 2, 3];

const result = array.reduce((acc, currentNumber) => {
  if(currentNumber >= 0) {
    return acc + currentNumber;
  }
  return acc;
}, 0);

Vue Native это обертка над React Native.
NativeScript это отдельный кроссплатформенный фреймворк который дает доступ к нативным компонентам платформы. И оба эти инструмента это не WebView.
NS использует движок V8 JavaScript для Android и JavaScriptCore для iOS. RN использует только JavaScriptCore
для обеих платформ. NS может в JS, TS, Angular и в этом году добавили официальную поддержку Vue за счет интеграции с плагином nativescript-vue
Можно в playground'e пощупать.

С RN я не работал, как и с VN, но мне интересно развитие NS.
В общих чертах RN и NS похожи, но отличаются архитектурой взаимодействия с родными модулями платформ.
NS работает c API интерфейсом платформы непосредственно в движке JS, отправляя вызовы и конвертируя данные на лету. При компиляции все XML компоненты передаются на собственные компоненты Android и iOS перед упаковкой в ​​двоичный файл платформы. В оф.документации все расписано
Есть хорошая статья в блоге NS, где они разбирают серию статей от Airbnb об опыте с RN.

Считаю что NativeScript недооценен сообществом, годный продукт.

Простые приложения можно строить и на NS, что то более сложное где память решает, лучше писать нативно.

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

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

На фронте у вас нет выбора, а на бэке вы можете выбрать хороший язык. Поэтому забудь про PHP и NodeJS, бери Python.

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

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

1. Хотелось бы услышать мысли опытных людей, кто использует, или использовал NodeJS, стоит ли тратить время на изучение/написание кода под данную платформу, или перспективнее с нуля учить PHP, Python итп.

Для того кто "знает жс" проще самому попробовать писать на ней вместо задавания таких общих вопросов

2. Что на данный момент с актуальность NodeJS на рынке СНГ или Запада. Количество вакансий, проектов итп. Растет ли NodeJS так же быстро, как он рос в 14-16 годы?

Все растет быстро. Если вы исходите из популярности, то вам лучше учить tiobe топ3

3. Техническая составляющая: изучая статьи про NodeJS, в большинстве из них писали, что NodeJS отлично подходит под огромное количество небольших запросов, но вот с прожорливыми запросами начинаются проблемы. Т.к. пишу в основном под web, то и вопросы будут относительно него. Целесообразно ли писать небольшие и средние (а высоко-нагруженные приложения?) сайты на NodeJS?

v8 коренным образом не поменялся.
Нагрузка бывает разная
Целесообразно использовать, то что лучше знаете - для малых и средних проектов не имеет значение ЯП

под огромное количество небольших запросов

подходит ерланг, а не нода

Вакансий и на чистый фронтенд полно, если добавите фуллстек на ноде - будет только плюс. Нода сейчас в тренде и позволяет писать быстрый бек.

Для бэкенда важнее знать подходы, архитектуру, библиотеки, базу данных, чем язык. И все это конечно займет больше времени.

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

Да, и крупные проекты тоже есть. Правда без ts тяжеловато такое писать. Nest.js возможно поможет.

Node JS это стандарт для многих компаний, уходить никуда не собирается, сообщество гигантское. Удобство разработки (один язык с фронтендом), гибкость и небольшой порок вхождения можно рассматривать как преимущества

if (pass = "Ivan")
замените на
if (pass === "Ivan")