As For JS

Четверг. 21-00 По Киеву Практика и теория сложности алгоритмов в контексте языка JavaScript Нужны ли алгоритмы JavaScript программисту, что такое Big O? Узнаем, что говорят об этом авторитетные источники. Получим минимально необходимый обьем знаний в теории сложности алгоритмов. Проверим на практике то, о чем шла речь. Эта трансляция, является ответом на записанную ранее трансляцию: Big O в JavaScript: инструмент разработчика или ненужная хрень?  Которую я считаю вредной и неверно формирующей отношение к проблеме у начинающего программиста. https://www.youtube.com/watch?v=Qfi0_0w0dsM

Сегодня в 4 - 10 утра по Киеву Разберем видео от Миши Ларченко Меня много раз просили прокомментировать видео от Миши Ларченко. Возьмем 4-ре из них: 1) JavaScript уничтожил интернет 2) EvenLoop в JavaScript простыми словами 3) Как работает асинхронность в JavaScript 4) Пойми замыкания в JavaScript https://www.youtube.com/watch?v=0mnjOf4ViX4

Четверг. 21-00 По Киеву Практика и теория сложности алгоритмов в контексте языка JavaScript Нужны ли алгоритмы JavaScript программисту, что такое Big O? Узнаем, что говорят об этом авторитетные источники. Получим минимально необходимый обьем знаний в теории сложности алгоритмов. Проверим на практике то, о чем шла речь. Эта трансляция, является ответом на записанную ранее трансляцию: Big O в JavaScript: инструмент разработчика или ненужная хрень? Которую я считаю вредной и неверно формирующей отношение к проблеме у начинающего программиста. https://www.youtube.com/watch?v=Qfi0_0w0dsM

Противостояние тучи и конспектов вышло на новый уровень. часть конспекта была вырвана из контекста.

Туча ревнует к конспектам

Я посмотрел видео про BigO от Климова. Что укрепило меня в моем мнении об этом человеке. Он не решился взять на себя самого отвественность, он подтянул туда Тимура, который не в курсе всего контекста диалога, чтобы поставить меня в неудобное положение, где я опустив Илью ниже плинтуса должен сделать тоже с Тимуром, человеком которого я безмерно уважаю. В очередной раз убедился в том, что я сильно когда-то хорошо о тебе подумал.

Хлопцям з підрозділу CORVUS 93 ОМБР вкрай потрібна наша з вами допомога. Дуже потрібна Антена для підсилення дронів, а також Коаксіальний кабель. Сума збору 151 500 гривень. Сума немаленька, але це дасть змогу хлопцям працювати в таких жахливих умовах. Прошу долучитися всіх небайдужих. Фотозвіт та чеки після отримання комплектуючих підрозділом. Для CORVUS 93OМБР 🎯 Ціль: 151 500 ₴ 🔗Посилання на банку https://send.monobank.ua/jar/3QQx9kZyk 💳Номер картки банки 4441 1111 2585 3568

Сегодня в 21-00 по Киеву Спроба Українською. Поговоримо з Дмитром про типи, змінні та хоістінг Які є типи в JS, чому Мурич говоре що змінних не має та що таке хостинг. Як треба відповідати на співбесідах. Про все це поговоримо з Дмитром, якого цікавить те, як не все це дивитись з глибини специфікації. https://www.youtube.com/watch?v=xp79fBrLlFw

На канале Бабіча сегодня был пост про Північ памʼятає! А от твоєму коду — необовʼязково. где речь шла про мемоизацию. От которого у меня возгорелась жопа, которая требовала уточнений Ееее бейба да ты вся горишь, я твой огнетушитель пыщь пыщь, пышь пышь. По сути Мемоизация - это термин, который пришел к нам в этом виде из FP программирования. Другие, тоже самое знают под термином кеширование - то есть процесс, когда сохранить результат работы какой то алгоритмической части будет дешевле, чем повторно выполнить эту алгоритмическую часть. Например, запрос ресурса у удаленного сервера может нам стоить 300мс. То есть каждый повторный запрос, это еще 300мс ожидания. В то же время, если мы сохраним в кеше результат работы запроса и будем возвращать его - это 1мс. Экономия в 300 раз. Ура кешированию и мемоизации. Рахсодимся? Нет. Во всем этом, важен сам факт сравнения - стоит ли процесс извлечения данных из кеша того? Может проще запросить их снова? Первое - что кеш может приносить пользу, понятно всем. А вот второе - а когда это начинает происходить, и является свяэщенным граалем мемоизации. Что говорится у Бабіча в посте: Если у Вас СЛОЖНЫЕ вычисления - используйте кеширование/мемоизацию Если у Вас существенные вычисления и повторяемость высокая - используйте кеширование/мемоизацию Все классно, только что такое СЛОЖНЫЕ вычисления или высокая повторяемость? Это все подобно формулировкам, сделайте хорошо когда можно сделать хорошо и никогда не делайте плохо когда плохо. Все это идет наперевес с использованием useMemo в реакт. Как пример того, насколько бездумно его могут использовать. И снова критерий - не используйте useMemo когда это плохо. И используйте когда хорошо. Чтобы дать хоть какую-то обьективную оценку, что хорошо, а что плохо - я лезу в код React для useMemo. И офегеваю от того сколько потребляет ресурсов эта возможность. Первое что напрашивается - никогда не используйте useMemo. Я лезу в документацию к React с целью выяснить, что они рекомендуют:

useMemo is a React Hook that lets you cache the result of a calculation between re-renders.

и далее - чтобы принимать решение о использовании useMemo, используйте профайлинг вашего кода. Dert Wider. Титры. Краткая памятка что делать: 1) Если Вы понятия не имеете о том, почему вам нужно кеширование/мемоизация - не используйте вообще ничего. 2) Чтобы узнать нужно ли оно Вам - профилируйте ваш код. 3) Найдя слабое место - используйте для начала специфическое решение, гвозядми прибитое к вашему коду, который вызывает проблемы. 4) Снова профилируйте. 5) Получили положительный отклик. Попробуйте внешнее решение подобное useMemo 6) Снова профилируйте Список ситуаций, которые должны вызывать у вас жгучее желание в одном месте попрофилировать ваш код: 1) Вызов внешних API особенно тех, которые напрямую связаны с IO: сеть, диск, формирование отображения 2) Одни и те-же математические вычисления, которые повторяются больше 5 000 раз. 3) Большая вложенность используемых методов 4) Вызов внутреннего метода, который приводит к одному из выше обозначенных поведений На что следует обратить внимание: любые внешние инструменты, подобные useMemo в реакт, сами по себе потребляют ресурсы. В случае useMemo - огромные. Вы можете легко оказаться в ситуации, когда решение для кеширования, написанное вами на коленке для вашего кода, будет работать на порядок быстрее внешнего, подобного useMemo. Если у Вас еще нет достаточного опыта в подобных вопросах то постарайтесь избавиться от любых стереотипов в голове. Вот вам пример

function doAdd (a, b) {
  return a+b
}

Вы точно знаете, что a и b всегда будут числами. Может ли тут потребоваться мемоизация? Ответ: Нет, до тех пор пока ваши числа Типа Number. И все может сильно измениться когда у вас числа типа BigInt.

Вместо ИГОГО Оценка сложности алгоритма BIG O, как и любая другая, в случае если за скобки выносится язык программирования, штука полезная но абстрактная. Которая становится столь больше бесползеной, сколько сложно работает язык программирования. Можно ли использовать BIG o для адекватной оценки JS кода? Можно, но при условии, когда на вход поадется не просто алгоритм, но алгоритм со всеми особенностями имплементации языка программирования JS. Без которых результат будет фальсифицирован. Как следствие, того, что никто не может представить всю сложность имплементации современного JS, использование BIG-O бесполезно. И намного проще, а главное надежнее использовать простое профилирование своего кода. Печать подпись. Примеры возникающие с тем же Array на равном месте, на канале AsForJS.

Еще раз про Big O и почему он бесполезен в JavaScript Есть целое направление в математике - оценка сложность алгоритма. Суть которой оценить какой алгоритм эффективнее другого. Big O - это один из методов оценки временной сложности алгоритма. Таких методов больше десятка разных. В JS сообществе получило распространение именно Big O по причине того, что на JS собеседованиях и в разных видео стали упоминать именно его игнорируя прочие. Почему Big O в JS это проблема. Оценка сложности алгоритма оценивает только сам алгоритм который был поставлен на вход той методологии которую мы выбрали. Он не оценивает стоимость имплементации этого алгоритма конкретным инструментом. Например языком программирования JS. Проблемы с оценкой становятся столь большими, сколь высоким уровнем абстракции пользуется выбранный инструмент. Язык JavaScrtip - это язык программирования с наибольшим уровнем абстракции. Иными словами, мы имеем дело со сферическим конем в вакууме. Когда оценка самого алогритма может радикальным образом расходиться со временем демонстрируемой самой реализацией. Простой пример: Реализация типа Array в V8 (реализации JS) устроена таким образом, что V8 самостоятельно выделает некоторый минимальный обьем оперативной памяти для обслуживания 4 елементов пустого Array. В том случае, если происходит ситуация, когда все 4 слота использованы, то есть мы добавили в наш Array 5 элемент, это приводит к тому, что V8 выделяет новую память в два раза больше чем ранее, КОПИРУЕТ в нее все элементы массива. Память использованная ранее, помечается на очистку GC. Теперь представим ситуацию, когда наш алгоритм требует оперированием на 4 элементов, а например 4 миллиардами эллементов. Представте ситуацию, когда все Слоты выделенные для этого Array уже заполнены. И тут алгоритм добавляет еще один элемент. Это заставит V8 скопировать 4 миллиарада эллементов в область памяти, которая согласно его алгоритму будет умножена на два. То есть потребует 8 гб памяти. Если оперативной памяти будет не достаточно, и мы работаем в системе, которая использует swap (дисковые IO) для решения подобных вопросов, то это приведет к интенсвиным IO с диском. Представим дальше, что наш алгоритм удаляет этот элемент из нашего 8млрд массива. Это приведет к обнулоению этой области памяти создания другой в два раза меньше. Снова IO со свапом. А теперь мы снова добавили элемент. И снова выделение памяти и снова IO. И теперь представим алгоритм, реализующий иную сложность, но потребляющий меньше памяти на столько, чтобы не попадать в коллизию выделения/обнуления памяти. Какой алгоритм будет работать быстрее? Нам уже нужно учитывать не только итерации, не только память, но и то, как быстро работает наше дисковое IO, какие лагоритмы используются там - и так далее. Как следствие, оценка временной сложности реализации алгоритма на языке JS, оказывается невозможной, без оценки возможностей самой реализации самого языка JS. Как следствие, BIG O, без учета особенностей имплементации V8 это сферический конь в вакууме. Который может дать как правильный прогноз так и совершенно противоположный. Другой пример из области теоретической механики Кто учился на специальностях подобных инфизу, наверняка проходил курс Теоретической механики. И должны помнить один из ее парадоксов: Пусть у нас есть катушка с намотаной на нее ниткой. Пусть отмотана часть нитки. Что будет если потянуть за эту нитку? Ответ - катушка будет наматывать нитку за которую мы тянем. Так вот Big O - это теоретическая механика, которая тем больше точна, чем ближе мы к тому набору упрощений которые используются для ее работы. В случае Big O - наиболее точная оценка дается если алгоритм реализован на языке ассемблера. И тем меньше чем выше уровень абстракации. В случае языка JS эта оценка может давать совершенно противоречивые результаты, в силу того, что под каждой строкой кода, лежит СВОЙ алогоритм издержки на реализации которого могут оказаться очень дороги.

Backend Developer (Node.js) — iGaming 📍 Формат: віддалено 📅 Зайнятість: фуллтайм / парттайм 💰 ЗП: обговорюється Ми — продуктова iGaming-компанія, що розробляє ігри та backend-рішення для онлайн-казино. Шукаємо досвідченого Node.js-розробника з реальним досвідом в iGaming, щоб підсилити нашу команду. Що потрібно робити: ⏺️ Розробка та підтримка backend-логіки (слоти, instant, crash) ⏺️ Робота з RGS, ігровими сесіями, ставками, API ⏺️ Масштабована архітектура та високе навантаження Вимоги: ▶️ 4+ років досвіду з Node.js + TypeScript ‼️ Обов’язковий досвід в iGaming ▶️ Добре знання SQL/NoSQL, WebSockets, REST ▶️ Розуміння механік iGaming: сесії, ставки, раунди Буде плюсом: ✅ Робота у гейм провайдері ✅ Досвід з NestJS, Redis, Kafka ✅ Робота з ігровими рушіями або RGS ✅ Участь у сертифікації ігор 📩 Надсилай відгук @growthac

Урезанная до 1 часа версия (без вопросов ответов) https://www.youtube.com/live/A6zgTaxo3R4

Кому нечем заняться. Задача про суть трансляции Естькод:

var theFetchList = [
  fetch("https://a.com"),
  fetch("https://b.com"),
  fetch("https://c.com")
];

Promise.all (theFetchList).then( console.log );

Заглянув в DevTols вкладку Network то мы увидим, что было отправлено паралельно три запроса, результат работы которых мы и увидели как реакцию на Promise.all после удачного их завершения. Задача: Сделайте тоже самое без Promise.all с использованием async function: 1) нельзя использовать любые методы Promise 2) НУЖНО, чтобы запросы шли не последовательно, а паралельно

Сегодня вторник в 21-00 по Киеву. Производительность Async Function Как работают Async Function. Разберемся в том почему Async Function не лучший выбор для эффективного кода. Посмотрим на примерах, как можно решить некоторые из них. https://www.youtube.com/watch?v=VfQiG2jATgQ

22-00 по Киеву Глазами реверс-инженера: Google Docs Internals [2] Во второй части, попробуем написать код, который будет использовать найденные Google action. Попробуем решить задачу, как нам интегрироваться в код Google Docs, при условии, что имена классов, функций, конструкторов и переменных все время меняются. https://www.youtube.com/watch?v=xUvdte3tzYM

Что я пытался донести, рассказывая о Замыканиях в контексте ECMA specifiation. Я придерживаюсь того мнения, что применение в обиходе какого-либо термина, должно нести что-то больше, чем просто название процесса. Например термин Expression (выражение) в рамках спецификации ECMAScript дает понять, что какая-либо часть языка, которая названа Expression - возвращает результат, который может использовать другой Expression, без необходимости формирования отдельного Statement. ( То есть этот синтаксис, может быть частью другого синтаксиса)

a + b; // Expression; Значит он может быть частью другого Expression
theArr [ a + b ];

Замыканиями в языке JavaScript, пытаются пояснить процессы, которые действительно отвечают, как минимум части теории замыканий. При этом, в самом языке JS существует очень простая для понимания концепция Environments, которая в отличии от Замыканий, полно и со всех сторон описывает ВСЕ части JS языка. В тоже время когда Замыкания, касаются только одного частного случая. Иными словами, это искусственный в рамках ECMA spec термин, который дублирует часть функциональности другого термина той же спецификации. Потому, мне хочется настаивать на том, что на каких либо собеседованиях использовать вопросы о замыканиях - порочно. Так как они, провоцируют у соискателя, изучение только той части теории, которой достаточно для ответа. И не больше. При этом - эта часть формирует ограниченное восприятие как самой теории, так и того что она описывает в части JS. И если уж спрашивать о замыканиях в JS, то спрашивать ВСЮ теорию, по крайней мере в ее фундаментальной части. И даже в этом случае я бы бухтел, потому, что это отвлекает от того, как описан язык современной спецификацией. Понимая которую, можно обьяснять ВСЕ типичные вопросы о "странностях" языка, таких как - потеря this как контекста, разницу в поведении для глобального окружения и функционального окружения, let/const vs var и т.д. и т.п. И, тем более, почему алгоритмы, используемые V8 для оптимизации кода работы с "переменными", работают именно так, а не иначе.

Сегодня вскр 21-00 по Киеву Глазами реверс-инженера: Google Docs Internals Попробуем вместе найти все, что можно найти и поковырять все что ковыряется. https://www.youtube.com/watch?v=2zKya01zYK4

Стрима сегодня не будет. Я в коматозе.