Diggy Diggy Deploy
@demimurych
Человек с ником Alex, папищик и настоящий упырь, крутил на пропеллере ИИ, в результате чего последний сделал две песни про
I am a dev and I’m pushing to prod ...
I am a dev and I’m pushing to prod ...
👍9❤1
Сегодня в четверг, 22-00 по Киеву
String in wild. Часть 3 из 3.
Это заключительная лекция о String в JavaScript, в которой мы поговорим о:
1) нормализации строк
2) доступных нам методов контроля за наличием в них ошибок
3) посчитаем графемы, слова, предложения
4) проникнемся регулярными выражениями
5) заглянем под капот V8, с целью узнать а как у него там дела
https://www.youtube.com/watch?v=cYxohlw4mV0
String in wild. Часть 3 из 3.
Это заключительная лекция о String в JavaScript, в которой мы поговорим о:
1) нормализации строк
2) доступных нам методов контроля за наличием в них ошибок
3) посчитаем графемы, слова, предложения
4) проникнемся регулярными выражениями
5) заглянем под капот V8, с целью узнать а как у него там дела
https://www.youtube.com/watch?v=cYxohlw4mV0
YouTube
String in wild. Часть 3 из 3.
Я наконец решился избирательно публиковать главы своей книги о JavaScript.
Пока буду делать это непоследовательно — выбирая те части, которые, как мне кажется, уже вряд ли претерпят существенные изменения.
Это заключительная лекция о String в JavaScript…
Пока буду делать это непоследовательно — выбирая те части, которые, как мне кажется, уже вряд ли претерпят существенные изменения.
Это заключительная лекция о String в JavaScript…
🔥23❤8😍1🐳1
#spec
Что такое Hoisting в рамках современной спецификации ECMAScript
Или что отвечать на собеседованиях.
Hoisting - это безграмотный жаргон закрепившийся в окружении JavaScript программистов, являющийся собирательным образом, для целой группы выражений таких как:
variable statement: var theVarThing = 1;
let/const declaration; let theLetThing = 2;
hoistable declaration ; function doThing() {};
и описывающий процесс, когда при формировании окружения, для выполнения кода функции, имена идентификаторов (theVarThing, theLetThing, doThing) которые используются этим окружением, должны быть заявлены в нем, ДО начала интерпретации кода.
Например:
Выполнение console.log не приводит к какой-либо, исключительной ситуации, потому что идентификатор theThingA уже был инициализирован значением undefined на момент старта интерпретации кода функции.
Именно этот процесс, и описывают безграмотным термином hoisting или всплытие.
Что говорит нам официальная спецификация
Официальная спецификация, содержит только один термин, с словосочетанием схожим со словом hoisting - это hoistable declaration.
Который касается только function declaration и только их. (В том числе производных, например генераторов_
Если бы, на уровне спецификации, существовал какой-то HOISTNG в той форме, в которой его спрашивают на собеседовании, то спецификация, обязана была бы включать в себя ВСЕ множество выражений - от var до function, а не только function.
В то же время спецификация описывает hoistable declaration СТРОГО КАК function declaration. Даже function expression не попадают под это определение.
Вместо ИГОГО
Никакого термина hoisting, в рамках официальной спецификации не существует, в той плоскости определения в которой его спрашивают на собеседовании. И никогда не существовало.
Есть группа выражений, содержащих ключевое слово function, поведение которых описано в спецификации под термом hoistable declaration. Под этим же термом нет И БЫТЬ не может никаких var let или const.
Процесс так называемого "всплытия", в спецификации, описан в стадии подготовки выполнения кода функции.
Подчеркиваю ПОДГОТОВКИ ВЫПОЛНЕНИЯ КОДА ФУНКЦИИ. той самой функции, которая оказывается hoistable declaration в том числе.
Краткий тезис -
если бы в спецификации был hoisting, как часть языка, то в нем бы описывалось все то, что привыкли спрашивать на собеседовании: var let const function
в то же время, в спецификации, есть термин hoistable который касается только function, и принципиально не может содержать var let или const.
Что такое Hoisting в рамках современной спецификации ECMAScript
Или что отвечать на собеседованиях.
Hoisting - это безграмотный жаргон закрепившийся в окружении JavaScript программистов, являющийся собирательным образом, для целой группы выражений таких как:
variable statement: var theVarThing = 1;
let/const declaration; let theLetThing = 2;
hoistable declaration ; function doThing() {};
и описывающий процесс, когда при формировании окружения, для выполнения кода функции, имена идентификаторов (theVarThing, theLetThing, doThing) которые используются этим окружением, должны быть заявлены в нем, ДО начала интерпретации кода.
Например:
function doThing() {
console.log( theThingA );
var theThingA = "AAAAAA";
}
Выполнение console.log не приводит к какой-либо, исключительной ситуации, потому что идентификатор theThingA уже был инициализирован значением undefined на момент старта интерпретации кода функции.
Именно этот процесс, и описывают безграмотным термином hoisting или всплытие.
Что говорит нам официальная спецификация
Официальная спецификация, содержит только один термин, с словосочетанием схожим со словом hoisting - это hoistable declaration.
Который касается только function declaration и только их. (В том числе производных, например генераторов_
Если бы, на уровне спецификации, существовал какой-то HOISTNG в той форме, в которой его спрашивают на собеседовании, то спецификация, обязана была бы включать в себя ВСЕ множество выражений - от var до function, а не только function.
В то же время спецификация описывает hoistable declaration СТРОГО КАК function declaration. Даже function expression не попадают под это определение.
Вместо ИГОГО
Никакого термина hoisting, в рамках официальной спецификации не существует, в той плоскости определения в которой его спрашивают на собеседовании. И никогда не существовало.
Есть группа выражений, содержащих ключевое слово function, поведение которых описано в спецификации под термом hoistable declaration. Под этим же термом нет И БЫТЬ не может никаких var let или const.
Процесс так называемого "всплытия", в спецификации, описан в стадии подготовки выполнения кода функции.
Подчеркиваю ПОДГОТОВКИ ВЫПОЛНЕНИЯ КОДА ФУНКЦИИ. той самой функции, которая оказывается hoistable declaration в том числе.
Краткий тезис -
если бы в спецификации был hoisting, как часть языка, то в нем бы описывалось все то, что привыкли спрашивать на собеседовании: var let const function
в то же время, в спецификации, есть термин hoistable который касается только function, и принципиально не может содержать var let или const.
👍33🔥14❤9🤯3
Напишите если Вам не в лом, какие еще термины типичных собеседований, вам интересно чтобы я прокомментировал.
Например: this - как контекст, TDZ - как темпорал деад зоне и так далее...
Например: this - как контекст, TDZ - как темпорал деад зоне и так далее...
🔥8❤1👍1
#spec
Что такое макротаски (macrotask) в рамках современной спецификации ECMAScript.
В рамках спецификации ECMA, такого термина, или его производных - не существует и никогда не существовало.
Такой термин действительно был, но только в рамках спецификации HTML5, части, которая касалась EventLoop.
В настоящий момент времени, в раках стандарта HTML5 в его части EventLoopt, принято говорить о: Task Queue и microtask queue. Которые выполняют совершенно разные функции.
То есть, в былинные времена, термин маркотаски, описывал то, что сейчас описано спецификацией HTML5 как Task Queue. Или просто очередь задач.
При этом, существующий сейчас термин, вводит в заблуждение в той части, когда говорит про ОЧЕРЕДЬ.
Спецификация HTML5 прямо указывает, что это НЕ ОЧЕРЕДЬ,
не смотря на существующее название.
Первый промежуточный итог:
Термин макротаск - это термин который не имеет отношение к JavaScript.
Этот термин, использовался в прошлом, в формате спецификации HTML5.
В настоящий момент, этот термин не используется. Вместо него используется термин Task queues.
Про который нужно знать, что, не смотря на присуствие слова queue - он НЕ ОБОЗНАЧАЕТ очередь задач.
Но обозначает какой-то список, из которого значения могут браться в произвольном порядке. (превед свидетелям одно-поточного JavaScript)
Про что следует знать:
Согласно стандарту HMTL5, к каждому списку task queues, прикреплен microtask queue. Последний является именно очередью, которая, согласно спецификации, гарантирует порядок исполнения, в соответствии с порядком постановки в очередь.
Как это связано с JavaScript:
Это очень сложный основополагающий вопрос того, как в принципе обеспечивается работа языка JavaScript солгасно спецификации.
Если говорить в ОЧЕНЬ УПРОЩЕННОЙ форме, то для выполнения какого-либо JS кода, это код, нужно поставить как Task Queue. В процессе выполнения которой, некоторые из частей языка, например Promise, могут формировать задачи, которые попадают в MicroTask Queue.
Но при этом, неправильно думать, что эти термины касаются именно языка JavaScript, потому, что в форме спецификации ECMA эти же очереди, описаны иначе: Jobs Queue (которая так же не является очередью) и Promise Quueue.
Чтобы раскрыть связь терминов HTML5: TaskQueue / MicrotaskQuesu (спецификации HTML5) и GenericJob / PromiseJob нужен очень долгий разговор, поясняющий связ между имплементацией стандарта и HOST средой.
Вместо ИГОГО:
Когда речь заходит про что-то, что использует слово Task, первое что нужно уточнить - вы о каком стандарте говорите.
Так как в рамках ECMA, существование GenericJob и PromiseJob это одна разница, в то же время когда в HTML5 Task Queue и Microtask Queue совсем другая. Не смотря на то, что они могут сильно пересекаться.
Что такое макротаски (macrotask) в рамках современной спецификации ECMAScript.
В рамках спецификации ECMA, такого термина, или его производных - не существует и никогда не существовало.
Такой термин действительно был, но только в рамках спецификации HTML5, части, которая касалась EventLoop.
В настоящий момент времени, в раках стандарта HTML5 в его части EventLoopt, принято говорить о: Task Queue и microtask queue. Которые выполняют совершенно разные функции.
То есть, в былинные времена, термин маркотаски, описывал то, что сейчас описано спецификацией HTML5 как Task Queue. Или просто очередь задач.
При этом, существующий сейчас термин, вводит в заблуждение в той части, когда говорит про ОЧЕРЕДЬ.
Спецификация HTML5 прямо указывает, что это НЕ ОЧЕРЕДЬ,
Task queues are sets, not queues, because the event loop processing model grabs the first runnable task from the chosen queue, instead of dequeuing the first task.
не смотря на существующее название.
Первый промежуточный итог:
Термин макротаск - это термин который не имеет отношение к JavaScript.
Этот термин, использовался в прошлом, в формате спецификации HTML5.
В настоящий момент, этот термин не используется. Вместо него используется термин Task queues.
Про который нужно знать, что, не смотря на присуствие слова queue - он НЕ ОБОЗНАЧАЕТ очередь задач.
Но обозначает какой-то список, из которого значения могут браться в произвольном порядке. (превед свидетелям одно-поточного JavaScript)
Про что следует знать:
Согласно стандарту HMTL5, к каждому списку task queues, прикреплен microtask queue. Последний является именно очередью, которая, согласно спецификации, гарантирует порядок исполнения, в соответствии с порядком постановки в очередь.
Как это связано с JavaScript:
Это очень сложный основополагающий вопрос того, как в принципе обеспечивается работа языка JavaScript солгасно спецификации.
Если говорить в ОЧЕНЬ УПРОЩЕННОЙ форме, то для выполнения какого-либо JS кода, это код, нужно поставить как Task Queue. В процессе выполнения которой, некоторые из частей языка, например Promise, могут формировать задачи, которые попадают в MicroTask Queue.
Но при этом, неправильно думать, что эти термины касаются именно языка JavaScript, потому, что в форме спецификации ECMA эти же очереди, описаны иначе: Jobs Queue (которая так же не является очередью) и Promise Quueue.
Чтобы раскрыть связь терминов HTML5: TaskQueue / MicrotaskQuesu (спецификации HTML5) и GenericJob / PromiseJob нужен очень долгий разговор, поясняющий связ между имплементацией стандарта и HOST средой.
Вместо ИГОГО:
Когда речь заходит про что-то, что использует слово Task, первое что нужно уточнить - вы о каком стандарте говорите.
Так как в рамках ECMA, существование GenericJob и PromiseJob это одна разница, в то же время когда в HTML5 Task Queue и Microtask Queue совсем другая. Не смотря на то, что они могут сильно пересекаться.
🔥25❤8👍4
#spec
Что такое асинхронность/много-поточность с точки зрения официальной спецификации ECMAScript.
С точки зрения официальной спецификации - эти термины НИЧЕГО не обозначают.
И никогда не существовали.
Откуда растут ноги?
В далекие былинные времена (1997 год - 2015 год), спецификация языка ECMA была устроена таким образом, что взаимодействие JS кода, с JS кодом, например в другой вкладке, организовать было невозможно. По крайней мере, используя только возможности ECMA спецификации.
В целом вся, спецификация, была написана таким образом, что код, который исполняется одной из вкладок блокировал любой другой код любой другой вкладки браузера.
В силу этого опыта, появляется ряд докладов, о JS, где подобное поведение оправдывается его(JS) односторонностью.
С чем, в целом можно согласиться.
С 2017 года, когда официальная спецификация ECMA реформирует работу языка, декларируя термин Мульти - Агент, когда в спецификации появляется Atomics API - язык JS получает ту форму, которая позволяет HOST среде, так выстраивать исполнение JS кода, как ей (HOST) среде хочется. В том числе предоставляя API для всех возможных (паралельных )форм исполнения кода.
С 2015 года, когда официальная спецификация ECMA получила описание Promise, мы получили возможность от HOST среды в рамках списка задач - GenericJob и очереди задач PromiseJob - регламентировать процесс работы с JS кодом.
Что все это значит
До 2015 года, не существовало никаких механизмов в рамках спецификации ECMA, которые бы позволяли управлять потоком исполнения JS кода. Что, например, в том числе приводило к тому, что код одной влкдаки мог блокировать код другой вкладки.
Это поведение породило массу докладов, где авторы рассказывали о одно поточности JS языка, обосновывая это примерами из поведения выше. То есть маркирование JS как одно поточного языка.
С 2015 года, появляется официальный механизм управления выполнения кодом задач в ECMA, что автоматически приводит к тому, что тот же пример с вкладками перестает работать. стал ли JS много-поточным? (только потому, что соседние вклкдки перестали виснуть?)
С 2017 года, появляется API взаимодейтсвия (ATOMICS Api) для доступа к одной и той же области памяти.
С 2017 года появляется формализация процесса, который называется Claster Agent, который является абстракцией над процессом, кода любое католичество програмного кода, может взаимодействовать друг с другом, но при этом исполнеяется разным агентом.
Что из всего это следует
Язык JS, который регламентируется спецификацией ECMA, получил согласно спецификации, фозвомжность взаимодейтсвия разных блоков кода, между собой в условиях, когда они имеют доступ к одной и той же области памяти.
Язык JS - это язык, той формы абстракции, который не отвечает и не может отвечать на вопрос, КАК решается эта задача: многопоточно, асинхронно, мульти-процессами, вытесняющей многозадачностью и так далее.
Это язык, который предоставил с 2017 года, HOST среде, решать задачи в несколько Агентов, которые(агенты) могут взаимодействовать между собой на уровне абстрактного API, которое может быть реализовано как многопоточно, последовательно так и и любой другой форме которую придумают или реализуют на машинном уровне.
Это не задача JS - решать какая форма взаимодействия. Его задача была только в том, чтобы дать возможность HOST среде это сделать, что и появилось частично в 2015, и более полно с 2017 года.
Вместо ИГОГО
В былинные времена, язык JS был устроен таким образом, что он не позволял организовать вычисление разного кода, который бы мог между собой взаимодействовать.
С 2017 года, такая возможность появилась.
При этом сама спецификация - не диктует форму такой работы. Ее это не волнует. Она предоставляет только асбтракцию, которая позволяет взаимодействовать между собой таким блокам кода (Atomics Api)
То есть - утверждать в какой форме работает JS код (асинхронной, много-поточной или хуеточной) мы не можем, за исключением того, что HOST среда, может выбрать сама на основании тех возможностей которые предоставляет своременная спецификация, работать так, как ей удобно.
Что такое асинхронность/много-поточность с точки зрения официальной спецификации ECMAScript.
С точки зрения официальной спецификации - эти термины НИЧЕГО не обозначают.
И никогда не существовали.
Откуда растут ноги?
В далекие былинные времена (1997 год - 2015 год), спецификация языка ECMA была устроена таким образом, что взаимодействие JS кода, с JS кодом, например в другой вкладке, организовать было невозможно. По крайней мере, используя только возможности ECMA спецификации.
В целом вся, спецификация, была написана таким образом, что код, который исполняется одной из вкладок блокировал любой другой код любой другой вкладки браузера.
В силу этого опыта, появляется ряд докладов, о JS, где подобное поведение оправдывается его(JS) односторонностью.
С чем, в целом можно согласиться.
С 2017 года, когда официальная спецификация ECMA реформирует работу языка, декларируя термин Мульти - Агент, когда в спецификации появляется Atomics API - язык JS получает ту форму, которая позволяет HOST среде, так выстраивать исполнение JS кода, как ей (HOST) среде хочется. В том числе предоставляя API для всех возможных (паралельных )форм исполнения кода.
С 2015 года, когда официальная спецификация ECMA получила описание Promise, мы получили возможность от HOST среды в рамках списка задач - GenericJob и очереди задач PromiseJob - регламентировать процесс работы с JS кодом.
Что все это значит
До 2015 года, не существовало никаких механизмов в рамках спецификации ECMA, которые бы позволяли управлять потоком исполнения JS кода. Что, например, в том числе приводило к тому, что код одной влкдаки мог блокировать код другой вкладки.
Это поведение породило массу докладов, где авторы рассказывали о одно поточности JS языка, обосновывая это примерами из поведения выше. То есть маркирование JS как одно поточного языка.
С 2015 года, появляется официальный механизм управления выполнения кодом задач в ECMA, что автоматически приводит к тому, что тот же пример с вкладками перестает работать. стал ли JS много-поточным? (только потому, что соседние вклкдки перестали виснуть?)
С 2017 года, появляется API взаимодейтсвия (ATOMICS Api) для доступа к одной и той же области памяти.
С 2017 года появляется формализация процесса, который называется Claster Agent, который является абстракцией над процессом, кода любое католичество програмного кода, может взаимодействовать друг с другом, но при этом исполнеяется разным агентом.
Что из всего это следует
Язык JS, который регламентируется спецификацией ECMA, получил согласно спецификации, фозвомжность взаимодейтсвия разных блоков кода, между собой в условиях, когда они имеют доступ к одной и той же области памяти.
Язык JS - это язык, той формы абстракции, который не отвечает и не может отвечать на вопрос, КАК решается эта задача: многопоточно, асинхронно, мульти-процессами, вытесняющей многозадачностью и так далее.
Это язык, который предоставил с 2017 года, HOST среде, решать задачи в несколько Агентов, которые(агенты) могут взаимодействовать между собой на уровне абстрактного API, которое может быть реализовано как многопоточно, последовательно так и и любой другой форме которую придумают или реализуют на машинном уровне.
Это не задача JS - решать какая форма взаимодействия. Его задача была только в том, чтобы дать возможность HOST среде это сделать, что и появилось частично в 2015, и более полно с 2017 года.
Вместо ИГОГО
В былинные времена, язык JS был устроен таким образом, что он не позволял организовать вычисление разного кода, который бы мог между собой взаимодействовать.
С 2017 года, такая возможность появилась.
При этом сама спецификация - не диктует форму такой работы. Ее это не волнует. Она предоставляет только асбтракцию, которая позволяет взаимодействовать между собой таким блокам кода (Atomics Api)
То есть - утверждать в какой форме работает JS код (асинхронной, много-поточной или хуеточной) мы не можем, за исключением того, что HOST среда, может выбрать сама на основании тех возможностей которые предоставляет своременная спецификация, работать так, как ей удобно.
❤18🔥10🐳2
#spec
Какой ответ про асинхронность/много-поточность от Вас ждут на типичном собеседовании
Что JS однопоточен, на основании того что такая абстракция как Agent сама не может распаралелить вычисления в несколько потоков.
При этом, можно заметить, что язык JS регламентируемый спецификацией ECMA - это язык того уровня абстракции, где такие вопросы как много поточность, или что-либо подобное не могут регулироваться, подобно тому, как не регулируются вопросы работы с памятью.
И если возникает вопрос о потоках, то следует уточнить: какая у нас имплементація спецификации (v8, spider monkey, coreJS) и в каком окружении сама эта имплементация работает.
Потому как тот же V8 в случае windows OS реализует мультипроцесную модель взаимодействия, когда в случае Linux - мульти потоковую.
Вместо ИГОГО
Не в рамках возможностей языка JavaScript оценивать как он работает - однопоточно или как-то еще. Это регламентирует HOST среда в рамках возможностей которые предоставляет спецификация языка.
Современная спецификация, позволяет организовать работу JS кода, в любой из доступных форм, при этом сама спецификация - никаких стурктур для этого(форм ИСПОЛНЕНИЯ кода) не предоставляет. Но делает это возможным как для HOST среды, так и для предоставляемого API
Какой ответ про асинхронность/много-поточность от Вас ждут на типичном собеседовании
Что JS однопоточен, на основании того что такая абстракция как Agent сама не может распаралелить вычисления в несколько потоков.
При этом, можно заметить, что язык JS регламентируемый спецификацией ECMA - это язык того уровня абстракции, где такие вопросы как много поточность, или что-либо подобное не могут регулироваться, подобно тому, как не регулируются вопросы работы с памятью.
И если возникает вопрос о потоках, то следует уточнить: какая у нас имплементація спецификации (v8, spider monkey, coreJS) и в каком окружении сама эта имплементация работает.
Потому как тот же V8 в случае windows OS реализует мультипроцесную модель взаимодействия, когда в случае Linux - мульти потоковую.
Вместо ИГОГО
Не в рамках возможностей языка JavaScript оценивать как он работает - однопоточно или как-то еще. Это регламентирует HOST среда в рамках возможностей которые предоставляет спецификация языка.
Современная спецификация, позволяет организовать работу JS кода, в любой из доступных форм, при этом сама спецификация - никаких стурктур для этого(форм ИСПОЛНЕНИЯ кода) не предоставляет. Но делает это возможным как для HOST среды, так и для предоставляемого API
❤25👍9👌1
Понедельник, 22-00 по Киеву
Посмотрим вместе: СОБЕСЕДОВАНИЕ НА MIDDLE FRONTEND РАЗРАБОТЧИКА. Уничтожение за 6 лет опыта
https://www.youtube.com/watch?v=e0DKj6JGDVQ
Посмотрим вместе: СОБЕСЕДОВАНИЕ НА MIDDLE FRONTEND РАЗРАБОТЧИКА. Уничтожение за 6 лет опыта
https://www.youtube.com/watch?v=e0DKj6JGDVQ
YouTube
Смотрим вместе YT: Ulbi TV, собеседование на Middle FrontEnd разработчика
Посмотрим вместе новое видео с Ulbi TV: СОБЕСЕДОВАНИЕ НА MIDDLE FRONTEND РАЗРАБОТЧИКА. Уничтожение за 6 лет опыта.
Ссылка на оригинал:
https://www.youtube.com/watch?v=OZPOO79Y4jk
Таймкоды:
будут после
AsForJs новости в Telegram: https://t.me/AsForJavaScript…
Ссылка на оригинал:
https://www.youtube.com/watch?v=OZPOO79Y4jk
Таймкоды:
будут после
AsForJs новости в Telegram: https://t.me/AsForJavaScript…
🔥13❤🔥3❤3👍2👀1
#spec
Замыкания с точки зрения официальной спецификации ECMA
Короткий ответ:
Формально, такой термин как замыкание - никак не описан спецификацией. Больше того, для пояснение работы любой из частей спецификации ECMA, термин замыкание - не требуется в принципе.
При этом нужно отметить, что такая абстракция, как замыкания, действительно применима к JS коду, по крайней мере частично.
Проблемы начинаются там, где об этом начинают спрашивать на собеседованиях, ожидая "правильный" ответ, который в лучшем случае, правильный только частично.
Длинный ответ:
....
Я понял что сломаю пальцы записывая этот ответ и решил включить трансляцию про это самое.
22-00 по Киеву
Замыкания с точки зрения официальной спецификации.
https://www.youtube.com/watch?v=RvYq-wt_GEU
Замыкания с точки зрения официальной спецификации ECMA
Короткий ответ:
Формально, такой термин как замыкание - никак не описан спецификацией. Больше того, для пояснение работы любой из частей спецификации ECMA, термин замыкание - не требуется в принципе.
При этом нужно отметить, что такая абстракция, как замыкания, действительно применима к JS коду, по крайней мере частично.
Проблемы начинаются там, где об этом начинают спрашивать на собеседованиях, ожидая "правильный" ответ, который в лучшем случае, правильный только частично.
Длинный ответ:
....
Я понял что сломаю пальцы записывая этот ответ и решил включить трансляцию про это самое.
22-00 по Киеву
Замыкания с точки зрения официальной спецификации.
https://www.youtube.com/watch?v=RvYq-wt_GEU
👍22🔥9❤3
Суббота 21-00 по Киеву
Глазами реверс-инженера: Google Docs Internals
Попробуем вместе найти все, что можно найти
и поковырять все что ковыряется.
https://www.youtube.com/watch?v=2zKya01zYK4
Глазами реверс-инженера: Google Docs Internals
Попробуем вместе найти все, что можно найти
и поковырять все что ковыряется.
https://www.youtube.com/watch?v=2zKya01zYK4
YouTube
Глазами реверс-инженера: Google Docs Internals
Поковыряемся во внутренностях Google Docs.
Таймкоды:
__будут после__
AsForJs новости в Telegram: https://t.me/AsForJavaScript
AsForJs Talks в Telegram: https://t.me/AsForJsTalks
*Поддержать маленького бородатого JavaScript-ра*
Карта Приват (Bobrov…
Таймкоды:
__будут после__
AsForJs новости в Telegram: https://t.me/AsForJavaScript
AsForJs Talks в Telegram: https://t.me/AsForJsTalks
*Поддержать маленького бородатого JavaScript-ра*
Карта Приват (Bobrov…
🔥12❤1
Forwarded from Metarhia/NodeUA - Node.js Ukraine Community
🧩 Практичний майстер-клас Тимура Шемсединова
🗓 5 липня о 15:00
Тема: ⚡️Фічі швидше на ⅓ без перероблення і багфіксів!
Розберемо техніки й підходи які дозволять вам:
1. Пришвидшити розробку
2. Знизять кількість багів
3. Зменшать час на підтримку чинної кодової бази
👨💻 Для кого ефір? — мідли, сеньйори
https://wep.wf/st7j67?utm_source=telegram_channel&utm_medium=t_shemsedinov&utm_campaign=stream_05_07
🗓 5 липня о 15:00
Тема: ⚡️Фічі швидше на ⅓ без перероблення і багфіксів!
Розберемо техніки й підходи які дозволять вам:
1. Пришвидшити розробку
2. Знизять кількість багів
3. Зменшать час на підтримку чинної кодової бази
👨💻 Для кого ефір? — мідли, сеньйори
https://wep.wf/st7j67?utm_source=telegram_channel&utm_medium=t_shemsedinov&utm_campaign=stream_05_07
❤1
Стрим про реверс Google Docs перенесен с сегодня 21-00
на сегодня, 11 утра.
Если Вам нечего делать в субботу утром, присоединяйтесь.
Там будет над чем подумать всем вместе.
https://www.youtube.com/watch?v=2zKya01zYK4
на сегодня, 11 утра.
Если Вам нечего делать в субботу утром, присоединяйтесь.
Там будет над чем подумать всем вместе.
https://www.youtube.com/watch?v=2zKya01zYK4
YouTube
Глазами реверс-инженера: Google Docs Internals
Поковыряемся во внутренностях Google Docs.
Таймкоды:
__будут после__
AsForJs новости в Telegram: https://t.me/AsForJavaScript
AsForJs Talks в Telegram: https://t.me/AsForJsTalks
*Поддержать маленького бородатого JavaScript-ра*
Карта Приват (Bobrov…
Таймкоды:
__будут после__
AsForJs новости в Telegram: https://t.me/AsForJavaScript
AsForJs Talks в Telegram: https://t.me/AsForJsTalks
*Поддержать маленького бородатого JavaScript-ра*
Карта Приват (Bobrov…
🤯6❤2🔥2👀2
И снова все перенеслось на 21-00 вечера по Киеву.
По этому поводу вспоминается один анекдот:
Маугли и Каа сидят под пальмой.
Маугли:
- Каа, а видишь вон на высокой пальме банан?
- Да Маугли вижу...
- А Багира сможет его достать?
- Нет, Маугли, не сможет.
- А Балу сможет его достать?
- Нет, Маугли, не сможет.
- А ты, Каа, сможешь его достать?
- Нет, Маугли, не смогу.
- А я смогу его достать?
- Ты, Маугли, кого хочешь достанешь...
Ваш маугли.
По этому поводу вспоминается один анекдот:
Маугли и Каа сидят под пальмой.
Маугли:
- Каа, а видишь вон на высокой пальме банан?
- Да Маугли вижу...
- А Багира сможет его достать?
- Нет, Маугли, не сможет.
- А Балу сможет его достать?
- Нет, Маугли, не сможет.
- А ты, Каа, сможешь его достать?
- Нет, Маугли, не смогу.
- А я смогу его достать?
- Ты, Маугли, кого хочешь достанешь...
Ваш маугли.
😁17🙏12❤4🐳3💯1
Разыскивается художник, который сможет нарисовать глаза реверс - инженера.
А то у меня не получаются.
У рисовалок с претензией на интеллект - тоже.
А то у меня не получаются.
У рисовалок с претензией на интеллект - тоже.
👀8😁4👨💻2❤1
Если Вам нечего смотреть вечером, посмотрите
wolf walkers
https://youtu.be/ord1YzvlDvs?si=mRY_lbBca0vW3CtW
wolf walkers
https://youtu.be/ord1YzvlDvs?si=mRY_lbBca0vW3CtW
YouTube
Wolfwalkers || Running with the Wolves || [SONG REMASTERED] {{Back-Up}}
This is a reupload in the event the original video gets deleted. I am not the original uploader. Please check them out via the links below and the cards provided in video. Original video can be found here:
https://www.youtube.com/watch?v=Rp6ehxZvvM4&ab_c…
https://www.youtube.com/watch?v=Rp6ehxZvvM4&ab_c…
❤8
Сегодня вскр 21-00 по Киеву
Глазами реверс-инженера: Google Docs Internals
Попробуем вместе найти все, что можно найти
и поковырять все что ковыряется.
https://www.youtube.com/watch?v=2zKya01zYK4
Глазами реверс-инженера: Google Docs Internals
Попробуем вместе найти все, что можно найти
и поковырять все что ковыряется.
https://www.youtube.com/watch?v=2zKya01zYK4
YouTube
Глазами реверс-инженера: Google Docs Internals
Поковыряемся во внутренностях Google Docs.
Таймкоды:
__будут после__
AsForJs новости в Telegram: https://t.me/AsForJavaScript
AsForJs Talks в Telegram: https://t.me/AsForJsTalks
*Поддержать маленького бородатого JavaScript-ра*
Карта Приват (Bobrov…
Таймкоды:
__будут после__
AsForJs новости в Telegram: https://t.me/AsForJavaScript
AsForJs Talks в Telegram: https://t.me/AsForJsTalks
*Поддержать маленького бородатого JavaScript-ра*
Карта Приват (Bobrov…
🔥17❤2🙏2🤯1👀1
Что я пытался донести, рассказывая о Замыканиях в контексте ECMA specifiation.
Я придерживаюсь того мнения, что применение в обиходе какого-либо термина, должно нести что-то больше, чем просто название процесса.
Например термин Expression (выражение) в рамках спецификации ECMAScript дает понять, что какая-либо часть языка, которая названа Expression - возвращает результат, который может использовать другой Expression, без необходимости формирования отдельного Statement. ( То есть этот синтаксис, может быть частью другого синтаксиса)
Замыканиями в языке JavaScript, пытаются пояснить процессы, которые действительно отвечают, как минимум части теории замыканий. При этом, в самом языке JS существует очень простая для понимания концепция Environments, которая в отличии от Замыканий, полно и со всех сторон описывает ВСЕ части JS языка. В тоже время когда Замыкания, касаются только одного частного случая.
Иными словами, это искусственный в рамках ECMA spec термин, который дублирует часть функциональности другого термина той же спецификации.
Потому, мне хочется настаивать на том, что на каких либо собеседованиях использовать вопросы о замыканиях - порочно. Так как они, провоцируют у соискателя, изучение только той части теории, которой достаточно для ответа. И не больше.
При этом - эта часть формирует ограниченное восприятие как самой теории, так и того что она описывает в части JS.
И если уж спрашивать о замыканиях в JS, то спрашивать ВСЮ теорию, по крайней мере в ее фундаментальной части.
И даже в этом случае я бы бухтел, потому, что это отвлекает от того, как описан язык современной спецификацией. Понимая которую, можно обьяснять ВСЕ типичные вопросы о "странностях" языка, таких как - потеря this как контекста, разницу в поведении для глобального окружения и функционального окружения, let/const vs var и т.д. и т.п.
И, тем более, почему алгоритмы, используемые V8 для оптимизации кода работы с "переменными", работают именно так, а не иначе.
Я придерживаюсь того мнения, что применение в обиходе какого-либо термина, должно нести что-то больше, чем просто название процесса.
Например термин 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👍9😁1