Sync-методы очень даже кузявые практически во всех случаях, когда у нас отсутствует concurrency: достать конфиги при старте приложения, работать с файлами в консольных утилитах, в написании тестов, какие-нибудь скрипты миграций и пр.
"pendingCallbacks" идёт перед фазой "poll" тут вообще никак не помогает.
Можно прикинуть пример с setImmediate, где это знание вам поможет понять, что происходит.
это знание никак не помогает мне понять как поведёт себя машина на скользкой дороге
Когда вы говорите "никак", вы прям категорично на этом настаиваете или это просто оборот речи? Мне кажется, вы вполне можете попробовать спрогнозировать поведение машины на основе своих знаний. Зная, как оно работает вы можете предсказать поведение с некоторой точностью.
Особенно занятно получилось про "путешествий во времени не бывает". Если бы мы писали такой код на PHP, то никаких событий, никаких await'ов бы там не было. Там было бы более интуитивно и последовательно: достали файл, прошли синхронно циклом, конец.
Вот тоже вполне себе решение, которое прямо вытекает из API:
const data = fs.readFileSync('file.txt', 'utf8');
const lines = data.split('\n');
for (let i = 0; i < lines.length; i++) {
console.log(lines[i]);
}
Но вы так не сделали. Именно потому что шарите за event loop :)
PS
Тип вашей блокировочной системы определяется ее внутренним устройством. Это же прямая взаимосвязь. Можно сказать "правильный ответ зависит от внутреннего устройства вашей блокировочной системы" и смысл не поменяется.
Ваше решение говорит о том, что вы понимаете асинхронность, событийную модель и стримы, имеете представление о том, как не блокировать поток и почему это важно. Я почти уверен, что вы сможете объяснить как работает event loop на собеседовании. Не нужно никаких тонкостей, речь шла про базовые вещи в прикладном контексте.
Про дифференциал чуть-чуть сложнее. Существует много разных механизмов блокировки. Зачем вам это знать? Если вы катаетесь в привычных условиях, где все предельно просто, можете не заморачиваться. Понимание механизма работы поможет вам, если у вас нет готовой инструкции. Дорога стала скользкой, включить ли вам блокировку? Правильный ответ зависит от типа вашей блокировочной системы.
Вы правы, если у вас есть готовый практический рецепт для решения любых проблем, замечательно. Но если у вас нет готового решения, вы можете его создать, имея понимание внутреннего устройства.
Для того, чтобы писать более эффективный код и не плодить баги. Например, попробуйте просто написать построчную обработку файла в Node JS или решить любую другую задачу, требующую асинхронной работы с чанками. Естественно с условием, что ваш код должен работать быстро и выдерживать большую нагрузку в ограниченных ресурсах сервера.
Если вы ездите на машине за продуктами в ближайший супермаркет, то да, вы просто нажимаете на педальку и едете. Но если вы в условиях оффроада, то придется разобраться, что такое блокировка дифференциала и как это работает. Иначе вы просто застрянете в грязи.
Так и большинство русскоязычных людей вам не смогут по памяти все части речи перечислить. Можете сами попробовать вспомнить, загибая пальцы, а потом провериться по википедии.
Большинству и не нужно. Тот факт, что вы умеете писать на русском, не делает вас специалистом в этой области. Если вы филолог/лингвист/преподаватель русского языка, то будьте добры загните все нужные пальцы. Вам за эти знания другие люди платят деньги.
Если же вы Node JS разработчик, пожалуйста, разберитесь с event loop.
Планируем и вам в скором времени предоставить соответствующий вашим требованиям инструмент в новой версии. Комменты уже так работают — есть галочка Markdown. Пишите как удобно.
Была когда-то веселая идея сделать суд присяжных из числа пользователей с положительной кармой. Можно было бы собрать дело о карме со всеми обстоятельствами случившегося и позволить сообществу самостоятельно принимать такие решения. И весело, и не нужна армия субъективных модераторов-судей :)
Спасибо за обратную связь. Идея поддерживать формулы "на лету" кажется очень хорошей и вполне вероятно, что получится ее реализовать. Остальные замечания также постараемся учесть. В частности тикет про "копирование поста" уже есть и в ближайшем будущем пойдет в работу.
Мы бы очень хотели довести редактор до состояния, когда вам удобно писать пост в "своём тёплом ламповом редакторе/IDE", а редактор "понимает" вас, реагирует адекватно и предсказуемо.
Именно! Видео без описания не очень. Интересно было бы увидеть техническое решение текстом и потом увидеть его "следы" в реальном бою.
Интересная тема. Продолжайте :) Но добавьте видео, пожалуйста — материал станет намного круче.
Не уверен, что именно механизм привода имеет решающую роль. Хотя смело предположу, что электромагнитная блокировка проявит себя лучше.
Вообще люди такими делами занимаются — исследуют устройство систем, чтобы повысить метрики эффективности.
Sync-методы очень даже кузявые практически во всех случаях, когда у нас отсутствует concurrency: достать конфиги при старте приложения, работать с файлами в консольных утилитах, в написании тестов, какие-нибудь скрипты миграций и пр.
Можно прикинуть пример с setImmediate, где это знание вам поможет понять, что происходит.
Когда вы говорите "никак", вы прям категорично на этом настаиваете или это просто оборот речи? Мне кажется, вы вполне можете попробовать спрогнозировать поведение машины на основе своих знаний. Зная, как оно работает вы можете предсказать поведение с некоторой точностью.
Особенно занятно получилось про "путешествий во времени не бывает". Если бы мы писали такой код на PHP, то никаких событий, никаких await'ов бы там не было. Там было бы более интуитивно и последовательно: достали файл, прошли синхронно циклом, конец.
Вот тоже вполне себе решение, которое прямо вытекает из API:
Но вы так не сделали. Именно потому что шарите за event loop :)
PS
Тип вашей блокировочной системы определяется ее внутренним устройством. Это же прямая взаимосвязь. Можно сказать "правильный ответ зависит от внутреннего устройства вашей блокировочной системы" и смысл не поменяется.
Ваше решение говорит о том, что вы понимаете асинхронность, событийную модель и стримы, имеете представление о том, как не блокировать поток и почему это важно. Я почти уверен, что вы сможете объяснить как работает event loop на собеседовании. Не нужно никаких тонкостей, речь шла про базовые вещи в прикладном контексте.
Про дифференциал чуть-чуть сложнее. Существует много разных механизмов блокировки. Зачем вам это знать? Если вы катаетесь в привычных условиях, где все предельно просто, можете не заморачиваться. Понимание механизма работы поможет вам, если у вас нет готовой инструкции. Дорога стала скользкой, включить ли вам блокировку? Правильный ответ зависит от типа вашей блокировочной системы.
Вы правы, если у вас есть готовый практический рецепт для решения любых проблем, замечательно. Но если у вас нет готового решения, вы можете его создать, имея понимание внутреннего устройства.
Для того, чтобы писать более эффективный код и не плодить баги. Например, попробуйте просто написать построчную обработку файла в Node JS или решить любую другую задачу, требующую асинхронной работы с чанками. Естественно с условием, что ваш код должен работать быстро и выдерживать большую нагрузку в ограниченных ресурсах сервера.
Если вы ездите на машине за продуктами в ближайший супермаркет, то да, вы просто нажимаете на педальку и едете. Но если вы в условиях оффроада, то придется разобраться, что такое блокировка дифференциала и как это работает. Иначе вы просто застрянете в грязи.
Большинству и не нужно. Тот факт, что вы умеете писать на русском, не делает вас специалистом в этой области. Если вы филолог/лингвист/преподаватель русского языка, то будьте добры загните все нужные пальцы. Вам за эти знания другие люди платят деньги.
Если же вы Node JS разработчик, пожалуйста, разберитесь с event loop.
Спасибо!
Возьмем в работу. @Nomad_77 Посмотришь?
А вот тут не очень просто. Например, «винтовка м16» или «макбук м2» не получится однозначно преобразовать в степень.
Согласно спеке markdown
__txt__именно про жирность, а не подчёркивание:В спеке маркдауна нет подчёркивания вообще. Или вы имеете в виду, что логично было бы кастомизировать такое правило для HFM?
Оно есть, можете делать вот так:
Добавьте
#в начало текста и нажмите пробел — получится заголовок первого уровня.Так же работает, например, для цитат
>[space]текстПланируем и вам в скором времени предоставить соответствующий вашим требованиям инструмент в новой версии. Комменты уже так работают — есть галочка Markdown. Пишите как удобно.
Была когда-то веселая идея сделать суд присяжных из числа пользователей с положительной кармой. Можно было бы собрать дело о карме со всеми обстоятельствами случившегося и позволить сообществу самостоятельно принимать такие решения. И весело, и не нужна армия субъективных модераторов-судей :)
К сожалению, с FF действительно все еще есть проблемы. Мы работаем над этим, но это не простая история.
Спасибо! Сейчас должно работать ок, без таких аномалий.
Могу предложить такой вариант, просто вставляете
>перед абзацемСпасибо за обратную связь. Посмотрим обязательно этот момент. И про Intl.Locale тоже.
Спасибо за обратную связь. Идея поддерживать формулы "на лету" кажется очень хорошей и вполне вероятно, что получится ее реализовать. Остальные замечания также постараемся учесть. В частности тикет про "копирование поста" уже есть и в ближайшем будущем пойдет в работу.
Мы бы очень хотели довести редактор до состояния, когда вам удобно писать пост в "своём тёплом ламповом редакторе/IDE", а редактор "понимает" вас, реагирует адекватно и предсказуемо.
Имеется в виду устарела в техническом плане.
Поправили функцию отключения.