Так оно и есть. Это как бы не десятая статья на хабре с паникой про падение продаж какой-нибудь электроники с далекоидущими выводами, и в десятый раз об этом пишут в комментариях вместо статьи.
Если бы кто-нибудь с серьёзным лицом сказал, к примеру, что повар должен уметь работать на грязной кухне, или что врач должен уметь работать в грязной операционной, он был бы немедленно поднят коллегами на смех. Когда кто-то на собеседовании проверяет умение лавировать вокруг банановых шкурок, свежего помёта птицы додо и наваленных граблей, это вызывает недоумение, и должно его вызывать. Не понимаю, как случилось, что среди программистов многие не понимают, что помойка это не нормальное состояние для рабочего пространства, и что в такой ситуации уборка в приоритете над всеми остальными задачами.
На десктопе производительность одного ядра интересна, потому что никто не собирается переписывать однопоточный код. При переходе на существенно отличающуюся архитектуру под шумок можно переписать многопоточно, если речь не идёт про какой-нибудь трудноподдерживаемый блоб на 10 миллионов строк кода вроде фотошопа. Если вдруг случится так, что на десктопах выгорит переход с х86 на что-то ещё, производительность на ядро будет чуть меньшей проблемой, чем может показаться.
Как-то я посмотрел на эти задачи, и... если у вас в проде null + 1 и мутация объектов в useEffect это норма, я бы не хотел у вас работать.
(Конкретно на этот вопрос правильный ответ: на initState забыт readonly, FC почему-то берётся из неймспейса руками, useCallback потерян, export default запрещён линтом, код не проходит ревью.)
Если вы читаете такие вещи где-то в медиа, то стоит рассмотреть несколько вариантов:
Это нужно, чтобы пробировать реакцию населения. Выбирается козёл отпущения, который будет якобы от своего имени вбрасывать идею, а если народу сильно не понравится, на него грозно помашут пальчиком и выдадут премию.
Это нужно, чтобы выработать толерантность к идее. Каждые месяца два кто-нибудь околовластный, но не совсем, вбрасывает идею немедленно призвать айтишников, и какое-нибудь минцифры под утомлённые и облегчённые вздохи обязательно скажет "нет". До того дня, пока оно не скажет "да", конечно.
Это нужно противоборствующей стороне, чтобы из тупого высказывания раздуть целый медиаповод, дабы побольше айтишников сбежало.
Где тут "хорошие" не совсем понятно. Не думаю, что от этого сильно меняется план действий для отдельно взятого айтишника.
Можно не менять, просто выплатить все открытые на этот паспорт мошенниками кредиты и всё.
То, что можно поменять паспорт с утёкшими данными, не изображая из себя идиота, постиравшего паспорт в стиралке, совершенно естественно. Делать это придётся каждые пару месяцев из-за полного отсутствия у бизнеса интереса в том, чтобы персданные не утекли.
Вы не обижайтесь на комментатора выше, он не в обиду. Дело в том, что это один из необходимых навыков для выживания в качестве предпринимателя, и совершенно неудивительно, что у вас он есть.
а ведь Джастин даже не сам написал эту программу, а использовал труд своего однокурсника Дмитрия Болдырева, а потом заплатил ему за молчание (если верить Дмитрию, конечно).
У этого есть простое объяснение: разработчики просто предпочитают использовать другие фреймворки. Обычно попробовавшие писать крупные приложения на Angular
К сожалению, обе ссылки так себе, и не описывают, как сделаны сами драйверы. На самом деле либо у драйвера на одну обмотку по одной ноге и ШИМ для микростеппинга (потому что как иначе MOSFETами усиливать полушаги? они ж сгорят без насыщения), либо там несколько ножек и каскад из MOSFETов, подтягивающих обмотку на разные уровни.
А, в случае switch там симметрично получается. Если мы делаем switch (x.type) где x: {type: 'a'} | {type: 'b'}, то после case 'a': case 'b': return; у нас останется x: never.
что делать с объектами, пришедшими снаружи
Если API "правильно" разработан, для них хватит и обычного narrowing. Иногда бывает и так, что API писали без типизируемости и эффективности валидации в уме, и придётся действительно ваять type guards. Но использовать небезопасные фичи ad hoc и по месту -- плохая идея, и стоит попытаться абстрагировать это в какой-то хорошо протестированный библиотечный код. Для парсинга внешних данных такие библиотеки уже, конечно, написали. zod вроде бы самая популярная из.
Best practice разработки на TS это всё-таки использовать как можно меньше фич языка, и использовать из них как можно более простые. Фичи вроде type guards и namespaces были добавлены в язык в основном для костыляния во время переезда проекта с JS. Безопасно предполагать, что если они вам где-то нужны, то либо на самом деле они не нужны, либо вы натолкнулись на баг, нашли/завели тикет, записали URL тикета в комментарий в коде, и попытались изолировать костыль вокруг этого бага с использованием этих фичей от остального кода.
Круто, теперь они могут полезть за обновлениями и стереть целых 44 ТБ ваших данных.
Так оно и есть. Это как бы не десятая статья на хабре с паникой про падение продаж какой-нибудь электроники с далекоидущими выводами, и в десятый раз об этом пишут в комментариях вместо статьи.
Я вот вроде бы на реакте давно пишу, а всё равно не понял, как между микротиками может пролезть клик. Точно так может быть?
Там места много. Мы столько двигателей не сделаем, чтобы на фоне солнечной радиации хоть какой-то эффект видно было.
Если бы кто-нибудь с серьёзным лицом сказал, к примеру, что повар должен уметь работать на грязной кухне, или что врач должен уметь работать в грязной операционной, он был бы немедленно поднят коллегами на смех. Когда кто-то на собеседовании проверяет умение лавировать вокруг банановых шкурок, свежего помёта птицы додо и наваленных граблей, это вызывает недоумение, и должно его вызывать. Не понимаю, как случилось, что среди программистов многие не понимают, что помойка это не нормальное состояние для рабочего пространства, и что в такой ситуации уборка в приоритете над всеми остальными задачами.
На десктопе производительность одного ядра интересна, потому что никто не собирается переписывать однопоточный код. При переходе на существенно отличающуюся архитектуру под шумок можно переписать многопоточно, если речь не идёт про какой-нибудь трудноподдерживаемый блоб на 10 миллионов строк кода вроде фотошопа. Если вдруг случится так, что на десктопах выгорит переход с х86 на что-то ещё, производительность на ядро будет чуть меньшей проблемой, чем может показаться.
Как-то я посмотрел на эти задачи, и... если у вас в проде
null + 1и мутация объектов вuseEffectэто норма, я бы не хотел у вас работать.(Конкретно на этот вопрос правильный ответ: на initState забыт readonly, FC почему-то берётся из неймспейса руками, useCallback потерян, export default запрещён линтом, код не проходит ревью.)
Если вы читаете такие вещи где-то в медиа, то стоит рассмотреть несколько вариантов:
Это нужно, чтобы пробировать реакцию населения. Выбирается козёл отпущения, который будет якобы от своего имени вбрасывать идею, а если народу сильно не понравится, на него грозно помашут пальчиком и выдадут премию.
Это нужно, чтобы выработать толерантность к идее. Каждые месяца два кто-нибудь околовластный, но не совсем, вбрасывает идею немедленно призвать айтишников, и какое-нибудь минцифры под утомлённые и облегчённые вздохи обязательно скажет "нет". До того дня, пока оно не скажет "да", конечно.
Это нужно противоборствующей стороне, чтобы из тупого высказывания раздуть целый медиаповод, дабы побольше айтишников сбежало.
Где тут "хорошие" не совсем понятно. Не думаю, что от этого сильно меняется план действий для отдельно взятого айтишника.
Можно не менять, просто выплатить все открытые на этот паспорт мошенниками кредиты и всё.
То, что можно поменять паспорт с утёкшими данными, не изображая из себя идиота, постиравшего паспорт в стиралке, совершенно естественно. Делать это придётся каждые пару месяцев из-за полного отсутствия у бизнеса интереса в том, чтобы персданные не утекли.
Об этом писали ещё под первой статьёй про выдачу брони.
Ну туповаты эти ребята, многоходовочки за полгода видно.
Вы не обижайтесь на комментатора выше, он не в обиду. Дело в том, что это один из необходимых навыков для выживания в качестве предпринимателя, и совершенно неудивительно, что у вас он есть.
Отсюда
А это потому, что на Северстали есть кому разъяснить.
У этого есть простое объяснение: разработчики просто предпочитают использовать другие фреймворки. Обычно попробовавшие писать крупные приложения на Angular
представляют погружение в Angular где-то так
А как будут выглядеть эти заголовки в старых статьях, если появится тёмная тема? Не думаю, что запрет делать это в новых статьях здесь чем-то поможет.
К сожалению, обе ссылки так себе, и не описывают, как сделаны сами драйверы. На самом деле либо у драйвера на одну обмотку по одной ноге и ШИМ для микростеппинга (потому что как иначе MOSFETами усиливать полушаги? они ж сгорят без насыщения), либо там несколько ножек и каскад из MOSFETов, подтягивающих обмотку на разные уровни.
А как микростеппинг в этих драйверах сделан?
А, в случае switch там симметрично получается. Если мы делаем
switch (x.type)гдеx: {type: 'a'} | {type: 'b'}, то послеcase 'a': case 'b': return;у нас останетсяx: never.Если API "правильно" разработан, для них хватит и обычного narrowing. Иногда бывает и так, что API писали без типизируемости и эффективности валидации в уме, и придётся действительно ваять type guards. Но использовать небезопасные фичи ad hoc и по месту -- плохая идея, и стоит попытаться абстрагировать это в какой-то хорошо протестированный библиотечный код. Для парсинга внешних данных такие библиотеки уже, конечно, написали.
zodвроде бы самая популярная из.Best practice разработки на TS это всё-таки использовать как можно меньше фич языка, и использовать из них как можно более простые. Фичи вроде type guards и namespaces были добавлены в язык в основном для костыляния во время переезда проекта с JS. Безопасно предполагать, что если они вам где-то нужны, то либо на самом деле они не нужны, либо вы натолкнулись на баг, нашли/завели тикет, записали URL тикета в комментарий в коде, и попытались изолировать костыль вокруг этого бага с использованием этих фичей от остального кода.
Как вы с таким подходом будете ссылаться на переменную из наружной области видимости, а не заводить новую с тем же именем?
Как присвоить в переменную на две области видимости выше текущей, но не проинициализированную там?