#spec
Замыкания с точки зрения официальной спецификации ECMA

Короткий ответ:
Формально, такой термин как замыкание - никак не описан спецификацией. Больше того, для пояснение работы любой из частей спецификации ECMA, термин замыкание - не требуется в принципе.

При этом нужно отметить, что такая абстракция, как замыкания, действительно применима к JS коду, по крайней мере частично.

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



Длинный ответ:
....
Я понял что сломаю пальцы записывая этот ответ и решил включить трансляцию про это самое.


22-00 по Киеву
Замыкания с точки зрения официальной спецификации.

https://www.youtube.com/watch?v=RvYq-wt_GEU

Суббота 21-00 по Киеву
Глазами реверс-инженера: Google Docs Internals

Попробуем вместе найти все, что можно найти
и поковырять все что ковыряется.

https://www.youtube.com/watch?v=2zKya01zYK4

🧩 Практичний майстер-клас Тимура Шемсединова
🗓 5 липня о 15:00
Тема: ⚡️Фічі швидше на ⅓ без перероблення і багфіксів!
Розберемо техніки й підходи які дозволять вам:
1. Пришвидшити розробку
2. Знизять кількість багів
3. Зменшать час на підтримку чинної кодової бази
👨‍💻 Для кого ефір? — мідли, сеньйори
https://wep.wf/st7j67?utm_source=telegram_channel&utm_medium=t_shemsedinov&utm_campaign=stream_05_07

Стрим про реверс Google Docs перенесен с сегодня 21-00
на сегодня, 11 утра.

Если Вам нечего делать в субботу утром, присоединяйтесь.
Там будет над чем подумать всем вместе.

https://www.youtube.com/watch?v=2zKya01zYK4

И снова все перенеслось на 21-00 вечера по Киеву.

По этому поводу вспоминается один анекдот:

Маугли и Каа сидят под пальмой.

Маугли:
- Каа, а видишь вон на высокой пальме банан?
- Да Маугли вижу...
- А Багира сможет его достать?
- Нет, Маугли, не сможет.
- А Балу сможет его достать?
- Нет, Маугли, не сможет.
- А ты, Каа, сможешь его достать?
- Нет, Маугли, не смогу.
- А я смогу его достать?
- Ты, Маугли, кого хочешь достанешь...


Ваш маугли.

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

У рисовалок с претензией на интеллект - тоже.

Если Вам нечего смотреть вечером, посмотрите

wolf walkers

https://youtu.be/ord1YzvlDvs?si=mRY_lbBca0vW3CtW

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

Сегодня вскр 21-00 по Киеву
Глазами реверс-инженера: Google Docs Internals

Попробуем вместе найти все, что можно найти
и поковырять все что ковыряется.

https://www.youtube.com/watch?v=2zKya01zYK4

Что я пытался донести, рассказывая о Замыканиях в контексте 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 для оптимизации кода работы с "переменными", работают именно так, а не иначе.

22-00 по Киеву
Глазами реверс-инженера: Google Docs Internals [2]

Во второй части, попробуем написать код, который будет использовать найденные Google action.
Попробуем решить задачу, как нам интегрироваться в код Google Docs, при условии, что имена классов, функций, конструкторов и переменных все время меняются.


https://www.youtube.com/watch?v=xUvdte3tzYM

Сегодня вторник в 21-00 по Киеву.
Производительность Async Function

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

https://www.youtube.com/watch?v=VfQiG2jATgQ

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

Естькод:

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

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

Заглянув в DevTols вкладку Network то мы увидим, что было отправлено паралельно три запроса, результат работы которых мы и увидели как реакцию на Promise.all после удачного их завершения.


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

Урезанная до 1 часа версия (без вопросов ответов)

https://www.youtube.com/live/A6zgTaxo3R4

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

Еще раз про 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 000 000 000 эллементов. Представте ситуацию, когда все Слоты выделенные для этого Array уже заполнены. И тут алгоритм добавляет еще один элемент.

Это заставит V8 скопировать 4 миллиарада эллементов в область памяти, которая согласно его алгоритму будет умножена на два. То есть потребует 8 гб памяти. Если оперативной памяти будет не достаточно, и мы работаем в системе, которая использует swap (дисковые IO) для решения подобных вопросов, то это приведет к интенсвиным IO с диском.

Представим дальше, что наш алгоритм удаляет этот элемент из нашего 8млрд массива.
Это приведет к обнулоению этой области памяти создания другой в два раза меньше. Снова IO со свапом.

А теперь мы снова добавили элемент. И снова выделение памяти и снова IO.

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

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


Как следствие, оценка временной сложности реализации алгоритма на языке JS, оказывается невозможной, без оценки возможностей самой реализации самого языка JS.

Как следствие, BIG O, без учета особенностей имплементации V8 это сферический конь в вакууме. Который может дать как правильный прогноз так и совершенно противоположный.


Другой пример из области теоретической механики
Кто учился на специальностях подобных инфизу, наверняка проходил курс Теоретической механики.
И должны помнить один из ее парадоксов:
Пусть у нас есть катушка с намотаной на нее ниткой.
Пусть отмотана часть нитки.
Что будет если потянуть за эту нитку?
Ответ - катушка будет наматывать нитку за которую мы тянем.
Это следствие упрощений теормеха.


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

В случае Big O - наиболее точная оценка дается если алгоритм реализован на языке ассемблера. И тем меньше чем выше уровень абстракации. В случае языка JS эта оценка может давать совершенно противоречивые результаты, в силу того, что под каждой строкой кода, лежит СВОЙ алогоритм издержки на реализации которого могут оказаться очень дороги.

Вместо ИГОГО
Оценка сложности алгоритма BIG O, как и любая другая, в случае если за скобки выносится язык программирования, штука полезная но абстрактная. Которая становится столь больше бесползеной, сколько сложно работает язык программирования.

Можно ли использовать BIG o для адекватной оценки JS кода?
Можно, но при условии, когда на вход поадется не просто алгоритм, но алгоритм со всеми особенностями имплементации языка программирования JS. Без которых результат будет фальсифицирован.

Как следствие, того, что никто не может представить всю сложность имплементации современного JS, использование BIG-O бесполезно. И намного проще, а главное надежнее использовать простое профилирование своего кода.

Печать подпись.

Примеры возникающие с тем же Array на равном месте, на канале AsForJS.

На канале Бабіча сегодня был пост про Північ памʼятає! А от твоєму коду — необовʼязково.
где речь шла про мемоизацию.
От которого у меня возгорелась жопа, которая требовала уточнений

Ееее бейба да ты вся горишь,
я твой огнетушитель
пыщь пыщь, пышь пышь.


По сути
Мемоизация - это термин, который пришел к нам в этом виде из 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 всегда будут числами. Может ли тут потребоваться мемоизация? Даже если это повторяется 100500 раз?

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

Сьогодні о 21-00 за Київом
Спроба Українською.

Поговоримо з Дмитром про типи, змінні та хоістінг

Які є типи в JS, чому Мурич говоре що змінних не має та що таке хостинг.
Як треба відповідати на співбесідах.
Про все це поговоримо з Дмитром, якого цікавить те, як не все це дивитись з глибини специфікації.

Попередження: Мова Мурича може звести вас до сказу, то якщо вас не переймає можливість паплюжити свої вуха - будь ласка долучайтесь.

https://www.youtube.com/watch?v=xp79fBrLlFw

Хлопцям з підрозділу CORVUS 93 ОМБР вкрай потрібна наша з вами допомога.
Дуже потрібна Антена для підсилення дронів, а також Коаксіальний кабель.
Сума збору 151 500 гривень. Сума немаленька, але це дасть змогу хлопцям працювати в таких жахливих умовах. Прошу долучитися всіх небайдужих. Фотозвіт та чеки після отримання комплектуючих підрозділом.

Для CORVUS 93OМБР

🎯 Ціль: 151 500 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/3QQx9kZyk

💳Номер картки банки
4441 1111 2585 3568