Comments 19
Знай свой инструмент


Что есть инструмент?
До какого уровня абстракции требуется опуститься, чтобы познать его?
В противовес Вашему утверждению, хочу выразить более разумный лозунг — «Делай свое дело эффективно».

Расходуй свое время эффективно. Развивай себя эффективно.

Часовщик на рисунке дает нам ясное представление, к чему приводит узконаправленное развитие личности — старик в свои седые годы вынужден работать больными руками, ибо он все свои силы положил на познание примитивного инструмента. Таким ли видят свое будущее свидетели «текучих абстракций»?)
И тем не менее, когда у вас сломаются часы, вы пойдете к этому старику. Я восторгаюсь и снимаю шляпу перед людьми, которые посвятили жизнь одному ремеслу. Да, они не универсальные солдаты, но настоящие профи и эксперты своего дела. Будь то плотник, кузнец или часовщик…
Я пойду к тому, кто сделает приемлемо по соотношению цена/качество)
Ну и чисто экономически не целесообразно специалистам вкладывать все яйца в одну корзину.

Тут как в любом деле — 90 процентов материала изучается по времени столько же, сколько и оставшиеся 10. А так как человек ограничен 24 часами в сутках, то чтобы получить максимальное количество полезных знаний ему необходимо собирать лишь те плоды, что уже созрели и лежат на земле. Это самый оптимальный путь в объективной реальности, что косвенно подтверждает обилие багов в софте, который пишут далеко не глупые люди)
А про абстракции, это, как я понял, отсылка к Джоелю Спольскому. И он, как раз в рассуждениях на этот счет, пример приводит с тем, что не достаточно нанять программиста, который знает только Visual Basic, К&Р тоже может понадобиться. Аналогия с libuv и node.js вполне себе.
Абстракции текут, но это не значит что течь должен устранять капитан судна)

"Компьютер — это конечный автомат". Алан Кокс, прим. Википедия


Блин, раньше считал, что сам это придумал.

Спасибо за полезную статью! Я не профильный JS разработчик, и у меня возможно нубский вопрос. Чем прикладному JS разработчику буду полезные эти знания в повседневной работе, ну и, соотвественно, почему этот вопрос популярен на собеседованиях. Можете привести примеры из реально жизни?
Я думаю, что это вопрос на понимание асинхронности и за счет чего она достигается. Ну а в js-жизни асинхронность ой как часто используется.
Поддерживаю ответ Fen1kz
До кучи, этот вопрос, как правило, идет следующим после вопроса о микро и макро задачах, которые как раз js-прикладник и использует в повседневной жизни.
Т.е. из разряда: «Чей обратный вызов сработает раньше setTimeout или setImmediate? Когда стоит применить то, а когда это?»
Или тот же вопрос, но с примером кода, где вы увидите лесенку асинхронных вложенностей из process.nextTick и setTimeout.
К вопросу про «микро и макро задачи». Не знал, теперь буду иметь в виду. Но опять же погружаясь в тему у меня возник вопрос. Вот тут в статье (правда за 2015 год) автор отлично на примере показывает отличие микро и макро задач, но тут же показывает что браузеры каждый по своему интерпретирует эту логику. Получается знать хорошо, но бесполезно? Получается что ноги растут из того же event loop, который в каждом движке отличается по своей реализации? Как дела обстоят с поддержкой на сегодняшний день?
Статья Джейка хороша, все верно, у каждого браузера свой js-движок, и реализация event loop своя, тут же речь о платформе Node.js, т.е. это не про браузеры, а про серверную js-технология. Она использует V8 (js-движок, тот же, что и в Chrome) и libuv для организации event loop и работы с файлами, сокетами, сетью, ОС и т.е.

К примеру, функций setImmediate (разве что нестандартизированная в FF) и process.nextTick в брузерах не найти, они характерны только Node.js платформе и ее событийному циклу.

libuv используется не только в node.js, есть и другие платформы.

Полезно ли знать это или нет — решать вам, решать каждому, я считаю, что полезно, затем и опубликовал заметку.
Спасибо что разъяснили. Моя невнимательность меня подвела. Я совсем не придал значение упоминанию в статья NodeJS, зато сразу ухватился на «javascript». Но собственно и доказывать что в информации нет пользы не было цели. Я хотел лишь увидеть практической значение этих знаний. Кое-что я для себя открыл! :) Спасибо!
По своему опыту собеседования порядка сотни человек скажу — чем больше у кандидата любознательности, тем лучше он себя показывает на практике. Ценный специалист старается понять внутренние механизмы работы системы, чтобы писать оптимальный код, объяснять (избегать?) необычное поведение или, например, искать лазейки. Очень рекомендую не ждать момента «когда это пригодится в реальной жизни», а прямо сейчас сесть и изучить в деталях то, с чем работаете.

«Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы»
Отличная формулировка

Ну и что то менеджер пакетов насчитывает столько модулей. Это разве заставляет вас их все учить?) вообще не понял про бежать в х2 быстрее к чему здесь)
Хорошая статья

Но после прочтения остаётся ряд вопросов. Что такое время таймера и что такое время цикла — не обозначается. Когда говорится об определении времени выполнения операции ввода вывода — тоже непонятно. Разве есть такие механизмы ядра, которые могут нам сказать, сколько времени будет выполняться асинхронная операция?) — ответ нет.
Потом что такое idle?) Дальше непонятно про что то вроде «благо мы знаем что в никсах все файл и тип одинаковый». Какая разница? Мы просто имеем дескриптор на сущность. В винде то же самое.

А мне ненравится, как в libuv сделаны таймера. Казалось бы — ну возьмите timerfd (для винды же тоже аналоги есть?), у них и прецезионность выше, и ненадо мудрить с таймаутами для epoll_wait(), и они поддерживают эвэнты не только по относительному — но и по абсолютному времени, и часы поддерживаются какие хочешь (монотонные, настенные...). И все это вокруг файлового дескриптора, то есть, делать вообще ничего ненадо.
На фоне этого, мудерж с таймаутами для epoll_wait() выглядит костылем.

На винде waitable timer только блокирующие. Кроме того, это же +1 системный вызов на операцию...

Ну, не знаю. Тогда, может и правильно, потому что при надобности timerfd пристыковывается при помощи структурки uv_poll_t.

Но при той реализации таймеров, которая в libuv — там эти таймера получаются не очень точные. И, насколько понимаю, при такой реализации у периодических таймеров не будет ни fixed rate ни fixed delay — а будет нечто среднее.
Only those users with full accounts are able to leave comments. Log in, please.