Владимир Солнцев

PING/PONG кидается раз в 20 секунд https://websockets.readthedocs.io/en/latest/topics...
PING/PONG фреймы — по одному байту. Плюс, если считаем, объём TCP и IP фреймов.

Итого за час 180 пингов и 180 понгов или 360 байт не считая оверхэда на нижележащие фреймы.
Если считать оверхэд, то примерно 65 байт x (180 пингов + 180 понгов) ~ 23кб/час

Плюс, какой-то оверхэд даст TLS и его хэндшейки, плюс, незначительный оверхэд дадут хэндшейки TCP. Но это явно не близко к 70мб

1)слишком много думаете.
2)слишком много рефлексируете и самокопаетесь
3)если вы действительно знаете что означают эти буквы что вы написали в сей простыне и у вас есть пет-проект по которому можете побеседовать - не занимайтесь ерундой и идите пробуйтесь и собеседуйтесь. Получив отказ проработайте открывшиеся лакуны и идите собеседуйтесь снова. Куда-нибудь да возьмут.
4)идите на любую должность в любую контору на любые деньги. Год поработаете, разберетесь - ищите новую работу уже как мидл, можете начинать всем рассказывать что программируете под свой андроид уже 20 лет (что, его ещё не было? а уже программировал, вот!), издеваться на форумах над 40-летними свитчерами, рассказывать как у них ничего не получится и "понаехали тут вайтишники, не продохнуть". Кто проверит-то.

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

https://developer.mozilla.org/uk/docs/Web/JavaScript

Используйте MutationObserver

return X; // тут НУЖНО ...

Не тут. Или не нужно. Потому что невозможно. Загрузка картинки выполняется асинхронно, так что возвращайте промис, который будет резолвится в true из обработчика onload и в false из onerror:

return new Promise(resolve => {
  const img = new Image();
  img.onload = () => resolve(true);
  img.onerror = () => resolve(false);
  img.src = 'тут ссылка на изображение';
});

https://learn.javascript.ru/operators#operator-zap...

просто слева направо вычисляются выражения, и последнее "возвращается"

console.log( (a = 4, a = a + 10, a) )
// 14

a[i%2] += b
собственно это прибавляет к элементу a[i%2] значение переменной b и возвращает массив

UPD
и да, я склоняюсь к мнению, что так лучше не писать :D

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

Итак, мы пишем на нашем высокоуровневом любимом языке, неважно JS/Rust/C#/Scala/Python или любой другой. В современном мире у нас скорее всего есть какая либо абстракция для работы с асинхронными апи, предоставляемая или стандартной библиотекой языка или сторонними библиотеками. Она может быть примитивной и основанной на колбэках или более продвинутой, вроде Future/Promise/Task или чем-то подобным. Иногда наш язык предоставляет синтаксис наподобие async/await для более простой работы с этими абстракциями, а иногда асинхронная работа может вообще быть скрыта от нас в рантайме языка, например как с горутинами в Go. Но в любом случае где-то под капотом у нас будет event-loop, а иногда и не один, так как никто не запрещает нам писать многопоточку в то же время используя асинхронные вызовы.

Сам event-loop - это не более чем обычный while(true) или любой другой бесконечный цикл. И внутри этого цикла наша программа имеет доступ на извлечение к некоторой очереди (если не знаете, что это за структура данных, то погуглите), которая содержит в себе результаты уже обработанных задач. Программа берет очередной результат, находит ожидающий ее колбэк/Promise/Future/Task и запускает выполнение ожидающего кода. Очередей опять же может быть несколько и обрабатываться они могут по разному, но это не важно. Важно то, что наш основной поток (или потоки) ничего не знают, о том как выполняются асинхронные задачи. Он лишь смотрит, есть ли в очереди результат, и если есть - обрабатывает его, а если нет, то принимает решение или выйти из цикла (и завершить поток, а иногда и весь процесс) или уснуть пока новых результатов не появится.

Но откуда же в очереди берутся результаты? Надо понимать, что асинхронная программа почти всегда многопоточная и результат операций попадает в очередь из фоновых потоков, которые просто блокируются в ожидании нужного ресурса (или сразу многих ресурсов, если используют системные апи вроде epoll или kqueue). Как правило такие фоновые потоки большую часть времени находятся в состоянии ожидания, а значит не потребляют ресурсы CPU и не попадают в планировщик ОС. Такая простая модель действительно позволяет сильно экономить ресурсы по сравнению с моделью, где множество потоков выполняют по 1 задаче и самостоятельно ожидают свои запросы.

Важно отметить, что в современном мире даже на среднеуровневых языках, вроде C или C++, не говоря уже о высокоуровневых, не реализуют асинхронность сами. Во-первых, на разных ОС для этого используются разные апи. Во-вторых, эти апи на разных ОС умеют обрабатывать разные типы ресурсов (с сетью вроде как умеют работать все основные ОС, но помимо сети асинхронно можно работать с пользовательским вводом, диском и периферийными устройствами, вроде сканеров, вебкамер и прочего цепляемого в usb). Наибольшую популярность (ИМХО) имеет кроссплатформенная библиотека libuv, хотя в Rust принято использовать mio (или даже абстракции над ней, вроде tokio), в C# подобные механизмы есть в .NET Core, а в Go оно уже зашито

Ок. С прикладным кодом вроде разобрались. А что же происходит в ядре ОС? Ведь, как писалось выше, у нас даже есть апи, чтоб ждать запросы пачкой. Все просто. Ядра ОС стали асинхронными еще до того, как это стало мейнстримом, если мы конечно имеем дело не с ОС реального времени (но у нас же винда/линь/мак/фряха, а не ОС для бортового компа боинга, где это критично). Смотрите, когда что-то происходит на внешней периферии (ну например диск запрошенные данные прочитал или по сети данные пришли, или юзер мышкой дернул), то формируется прерывание. CPU реально прерывает свою текущую работу и бежит смотреть что случилось, точнее вызывает обработчик предоставленный ОС. Но у ОС то есть основная работа, поэтому она скорее старается освободить обработчик и просто скидывает все данные в оперативку, а разбираться будет потом, когда очередь дойдет. Ничего не напоминает? Очень похоже, на то что происходило в event-loop, только вместо фоновых потоков "результаты" попадают в очередь из прерываний. А уже когда-то потом ОС отдаст данные в драйвер устройства, ну и т.д., пока они не дойдут до нашего прикладного приложения. Вот и все, никакой магии.

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

1) Один из этапов собеседования всегда связан с алгоритмами (даже несмотря на то, что в работе они использоваться не будут).

Алгоритмы используются постоянно. Мы не только JSON перекладываем :) Один разработчик может писать код день, в то время как другой сделает больше и лучше за 2 часа. Потому что у него лучше базовые знания, алгоритмы, иногда теория и опыт. Или ситуация, когда нужно разобраться в новой незнакомой технологии, системе. Тут тоже поможет умение быстро решать задачи, анализировать проблемы.

2) Как правило, собеседование состоит минимум из трех этапов.

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

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

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

4) Заработная плата ниже, чем в среднем по рынку.

Такое заблуждение присутствует, согласен, иногда слышу. Поговори с теми, кто уже тут работает давно, что они скажут.

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

что именно с точки зрения специалиста может получить программист, который пойдет к ним работать? Особенно опытный.

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

const parse = float => parseFloat(float.replace(/,/g, ''));

const number = parse(objectFloat.param1) + parse(objectFloat.param2); // 2353.66
console.log(number.toLocaleString('en-US')); // 2,353.66

Есть вероятность что i в вашем блоке не существует, уберите замыкание

var i = 0;
while(i < 3){
     $(list[i]).change(function(){
...

const form = document.querySelector('#promoCode');
form.childNodes.forEach((elem) => elem.nodeType === document.TEXT_NODE && elem.remove());