Работаем с двумерной графикой в JavaScript

Что касается коллизий — в статье даже не упомянули о самом интересном: что будет, если шаг (скорость * dt) будет больше чем сумма радиусов сталкивающихся объектов.

Работаем с двумерной графикой в JavaScript

Вы уверены, что понимаете что переводите в этом месте?

   for (let [i, o1] of o.entries()) { // для каждой пары объектов
        for (let [i, o2] of o.entries()) {
            if (i < j) { // делаем одно и тоже дважды для каждой пары
            ...

Создание небольшого API на Deno

В ноябре 2019 замержили поддержку lock-файлов (by hash).

Работаем с аудио: прогресс и визуализация данных

И ещё один момент по поводу:

Результат такой же, как при использовании try/catch, но пришлось написать целую функцию

Дело в том, что

catch(everyErrorIDontCare) { return; }

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

Считается, что допустимо использовать try/catch при выполнении трех условий:

1. без ошибок никак иначе не обойтись
2. минимально необходимое тело try
3. выброс необработанной ошибки наружу

try {
  audio.volume = 1.1;
} catch (err) {
  if (err instanceof DOMException && err.name === 'IndexSizeError') {
    return;
  } else {
    throw err; // pass any other unhandled error
  }
}

Но всё это совершенно не оправдано в нашем случае. И не красиво.

А вот функция clampNumber() — вполне self-explaining code. Ведь вам сам API как бы говорит: «программист, позаботься о том, чтобы громкость была в интервале от 0 до 1, иначе я ломаюсь».

Работаем с аудио: прогресс и визуализация данных

Ага, кажется понял о чем вы. «Странные» некруглые значения громкости — это всего лишь артефакт того, что значение храниться во float.

В нормальных (ирония) языках вроде C, где есть отдельно целочисленные и плавающие типы, такое поведение — обычное дело. Там никого не удивишь, что 0.0001 + 0.0002 != 0.0003. А в javascript число представлено одним универсальным типом IEEE 754 binary64. Что позволяет однозначно закодировать (в том числе и) диапазон целых чисел от Number.MIN_SAFE_INTEGER до Number.MAX_SAFE_INTEGER и как будто бы ожидать от number поведение, свойственное для integer в других языках: 123 + 456 == 579 строго. И это ослабляет бдительность. Ведь по-прежнему 0.1 + 0.2 == 0.30000000000000004

А в нашем случае вообще происходит итеративное сложение, которое за каждую операцию накапливает в себе ошибку. Так что это поведение абсолютно нормально. Чтобы видеть красивые ровные проценты в UI — отображаемое значение необходимо округлить. Это стандартная практика.

Открытие портов 4321 и 9898 на шлюзе Xiaomi Gateway 2

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

Работаем с аудио: прогресс и визуализация данных

Давайте попробуем разобраться что происходит тут:

необходимость использования try/catch обусловлена странным поведением Chrome, связанным с вычислением громкости звука. Попробуйте убрать try/catch и выводить в консоль громкость звука (console.log(audio.volume)) после каждого изменения при приближении к 0 и 1 (согласно спецификации значение громкости звука варьируется от 0.1 до 1) получаем странные значения, которые нивелируют проверки типа if(audio.volume>0 && audio.volume<1). Использование в проверках «неточных» значений вроде 0.1 и 0.9 решает проблему исключений, но приводит к некорректному изменению громкости звука. Исключения работе плеера не мешают, но раздражают

Мне стало интересно, я попробовал воспроизвести и не совсем понял в чем заключается «странное поведение»: у меня в Chrome console.log(audio.volume) выдает предсказуемые значения в диапазоне (0;1]. А такое решение у вас работает или тоже падает/ведет себя странно?

согласно спецификации значение громкости звука варьируется от 0.1 до 1

Нет, от 0 до 1.

Как работает парктроник и как его обмануть

У меня есть ощущение, что «использование микроконтроллера оправдано всегда». Это даже почти не шутка. Учитывая сколько они стоят и какие возможности по неинвазивной кастомизации дают в процессе эксплуатации и доводки.

Даже в этом «сделал-и-забыл» случае, посчитать схему просто в симуляторе с первого раза не удастся и придется тестить результат на железе. Если нужно подобрать сопротивление — ладно, есть подстроечный. Но если зайти чуть дальше, то по мне, менять прошивку куда как веселее чем паять.

Возможно это просто у меня деформация — я с паяльником никак.

Как работает парктроник и как его обмануть

А я думаю, в первую очередь по тому, что:

Сергей Whitech
Embedded Programmer

Если есть молоток, все проблемы кажутся гвоздями

Как работает парктроник и как его обмануть

Само собой. Используем все источники информации — перемножаем вероятность ошибки. Как в космонавтике.

Работаем с аудио: прогресс и визуализация данных

Добавлю, что в Chrome и Safari playTrack() можно запустить только синхронно из события, порожденного пользовательским взаимодействием (ondrop, ochange, onclick, ontouch, etc). Другими словами, автопроигрывание запрещено (слава богу?).

Как работает парктроник и как его обмануть

Люди допускают ошибки.

70 вопросов по JavaScript для подготовки к собеседованию

То что я его не совсем корректно поставил

Не «не совсем корректно», а «совсем не корректно». Таким он и продолжает быть после третьей итерации.

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

Его тон был вполне справедливым ответом на ваше высокомерие вкупе с высказанным заблуждением ещё здесь:

Вообще, в зависимости от того, как мне отвечают на этот вопрос я понимаю знает ли человек принципы работы JavaScript или сразу с React начал.

Мне 36 лет и моя основная специализация с 2007 года — javascript. И я до сих пор ещё ни разу не собеседовал джунов, представьте. Именно потому что всё ещё не уверен на 100% в своих силах. И очень не хочу выглядеть так, как вы сейчас. Это большая ответственность. Не перед компанией за то, что провороните ценный кадр, а перед соискателем. Он видит в вас авторитет. А вы ему не соответствуете в должной мере.

Как работает парктроник и как его обмануть

Не понимаю за что так минусуют ваш пост.
Не ставить все датчики (при том что душа «желала она чего-то более штатного») — это, конечно, капец странное решение. Но не вижу в этом никакого повода ставить минус статье.

70 вопросов по JavaScript для подготовки к собеседованию

это же и есть общий скоуп, который автор вопроса советует избегать

Не вижу ничего плохого в общем скоупе на async\await. Просто именно на промисах общий скоуп выглядит уродливо. Как впрочем и вложенные промисы. Потому мы и любим async/await.
Я за это:

async function doSome() {
    const a = first();
    const b = second();
    const c = third(await a, await b);
    // if u afraid that await will 'block the scope'
    // just do not place code here that must run berfore a and b resolves
    // place it in main() instead - it's a pretty common sense
    return await c;
}

async function main() {
    const c = doSome();
    doSomeElse(); // run "parrallel" task here
    return await c;
}

70 вопросов по JavaScript для подготовки к собеседованию

Нет, вопрос был совершенно не об этом. Все каменты сохранились, в этом легко убедится.

Вы именно что с апломбом (согласен с JustDont ) пришли в пост, высказали неверное утверждение, а сейчас вьётесь как уж на сковородке.
Сначала у вас было разное поведение setTimeout/setInterval в неактивной вкладке, потом вдруг блокирующие операции (хотя каментом раньше вы писали об анимациях), сейчас вдруг какой-то сломаный пинг. Что это вообще?

setInterval(() => slowRequestMock(counter++), 0);

По существу последнего примера (игнорируя ошибку с setInterval(fn, 0)): в вашем примере принципиальное отличие не в setInterval/setTimeout а именно в вашей реализации: вы зачем-то во втором случае реализовали по сути onDoneCallback, а в первом нет. Уберите nextPing() из тела коллбека setTimeout в тело slowRequestMock и разницы не будет.

По сути вообще: Вы сказали чушь. Что простительно. При этом, используя фамильярный тон («Вас бы я не взял», «Вам бы я советовал поработать над Soft Skills») Что сомнительно. А теперь вместо того чтобы признать свою неправоту, сливаетесь. Что выглядит просто жалко.

Не хотел бы я оказаться с вами на одном интерьвью. Но вы меня и не возьмёте, я понял. :)

70 вопросов по JavaScript для подготовки к собеседованию

То есть, если завернуть мой вариант в (async () => {})(), то решение верное? Если так, то я собой доволен.

А по-поводу никаких «eval или Function», как вам такое:

setTimeout('console.log("there is one more way to evaluate string")', 0);

70 вопросов по JavaScript для подготовки к собеседованию

Консенсус! :)

70 вопросов по JavaScript для подготовки к собеседованию

Да, я думаю, ключевое непонимание вышло из-за того, что в MDN написано:

быстрейший и предпочитаемый способ конвертирования чего-либо в число

а автор пишет:

является самым быстрым способом преобразования строки в число

т.к.

parseFloat(true) = NaN
+true = 1

И видимо, об этих дополнительных операциях шла речь. Только автор ничего не понял. И написал всё это про число-в-строку, обогатив мир ещё одним авторитетным домыслом.

PS: конвертация всего-что-угодно в строку — верный признак плохого кода.

70 вопросов по JavaScript для подготовки к собеседованию

Как-то миновало. :)

Так?

new Promise((resolve, reject)=> { reject(new RangeError('pizza size is too big'))});