Программа пишется на языке программирования, но в программном коде идентификаторы (переменные, функции, классы) в подавляющем большинстве коллективов принято называть именно на английском. Или, точнее сказать, используя лексику английского языка, поскольку правила грамматики, артикли и т.п. часто игнорируются.
Например, пишем class IncomingCurrencyPayment {}, а не class ВходящийВалютныйПлатеж {}
Я готов принять, что ограниченный закрытый список неизменных ключевых слов языка типа if, then – это заимствования из английского. Но, с моей точки зрения, было бы лукавством утверждать, что слово IncomingCurrencyPayment – это слово языка JavaScript, а не английское словосочетание. Можно сказать это, наплевав на семантику, но тогда вы утрачиваете полезное различение, затрудняя самому себе обсуждение вопроса.
Поддержу. В моей практике разрабатывал приложение на тему статистики населения, где все крутилось вокруг 4-х гиганстких структур данных по 100+ полей с глубоким вложением. Все поля в ТЗ именовались в соответствии с нормативной базой в виде многословного русского канцелярита, но который всем знакомым с предметной областью знаком и понятен.
И мы для каждого поля пытались придумать перевод на английский. Перевод многих полей оказался неочевидный и/или непривлекательный. По итогу, пришел к выводу, что смысла этот перевод не принес никакого. Пожалуй, стоило оставлять кириллицу (ну или на худой конец транслит).
Позвольте с вами не согласиться: "поле" совсем не обязательно только про землю и злаки. Специально проверил в НКРЯ: "предметное поле" или "проблемное поле" не сильно уступают по частотности "предметной области". Правда, без прилагательного действительно глаз немного режет и отдает англицизмом
Ключевая мысль, пожалуй, в том, что фокус – это важный и ограниченный ресурс, который многие растрачивают по мелочам. А польза и применимость каждой конкретной практики неизбежно зависят от субъективных особенностей человека и условий труда.
Честный ответ в том, что далеко не все эти практики у меня получается стабильно поддерживать на ежедневной основе.
Часть внедрить было весьма легко. Например, нетрудно встать в 5 утра, когда я знаю, что это нужно, чтобы с кайфом провести время на корте для бадминтона)
Отключить уведомления тоже не сложно. Настроил режим "не беспокоить" по расписанию, затем отключил уведомления для всех приложений, которые любят слать рекламные пуши, и от всех чатов в телеграме, кроме важных личных чатов. Это несложное разовое действие, но большая инвестиция в фокус и свободное время в дальнейшем.
А вот начать бежалостно вычеркивать лишнее из todo-листа или перестать давать нереалистично короткие оценки сроков было куда сложнее. Не уверен, что есть универсальный способ все это внедрить, но он явно должен строиться вокруг поиска личной мотивации – через рефлексию и осознание ценности для себя, но вряд ли через самопринуждение.
Начинал промышленную разрбаотку как раз с .NET, а сейчас на TS пишу. Как же было приятно иметь дело с LINQ, где с любой коллекцией единообразная работа. А то в JS реально, как автор пишет, есть .length, есть .size , есть, не дай бог, еще Object.values({ /* ... */ }).length. А чтобы сумму по массиву посчитать приходиться городить reduce каждый раз... Ну либо lodash тащить...
SLA в 100% может быть даже вреден, поскольку достижим только при условии полного отсутствия изменений, а бизнес такой долго не живет. Да, тестировать фичи на проде в банке не стоит, но все-таки в любых изменениях нужно закладывать шанс на ошибку. Важно не 100% SLA, а наличие продуманных и отлаженных механизмов восстановления доступности для разных сценариев сбоев.
Имеется в виду обратная совместимость новой версии движка с кодом, написанном на старых версиях стандарта ECMAScript. В этом смысле внедрение нового синтаксиса`async/await` не является ломающим изменением и сохраняет обратную совместимость движка. Но старые браузеры, вы правы, тут совершенно ни при чем.
Ну вот я все равно не понял. Например, у нас подключен бот Renovate, который автоматом создал нам МР с обновлением версии дизайн-кита (скажем, Taiga UI). Прежде чем жмякнуть "Merge", хочется как-то убедиться, что этот апдейт не принес нам неожиданных изменений в верстке, цветах, шрифтах и т.д. Даже при самой аккуратной работе создателя библиотеки, он едва ли сможет гарантировать, что изменения, вносимые в библиотеку не приведут к проблемам ни у одного из потребителей.
Вот недавно у нас как раз был кейс, когда в UI-кит добавили отдельную цветовую тему для мобильных устройств. Так вот у нас из-за того, что тема подключалась в приложение не так, как того стала требовать новая версия либы, мобильные цвета стали применяться и на десктопе. И если б не скриншоты, мы легко могли пропустить эту проблему на прод.
К тому же иногда, изменения вносятся умышленно. Например, меняется размер скруглений у элементов. Разумеется, мы хотим увидеть, как выглядит новый вариант нашего приложения, чем отличается от предыдущего и провести дизайн-ревью. Делать это со скриншотами явно легче, чем руками регрессить приложение на тестовом контуре.
Тут вы не совсем правы. Просто для примера, Т-Банк разрабатывает и продает чисто IT-шные продукты для рынка: Sage, Statist, Unidraw. Крупные банки являются драйверами развития нейросетевых технологий в России – причем как в продуктовом внедрении, так и в рисерче. Даже в опенсорс выкладывают.
Крупные компании РФ (в том числе известные в первую очередь как банки) стало не так-то легко классифицировать, потому что часто это холдинги с целым зонтиком юрлиц и направлений, включая IT. Сбер, например, участвует в разработке "программно-аппаратных" беспилотных тракторов.
P.S. Да, я работаю в Т, поэтому про него так много и пишу, но он такой не один)
Вы только что популярно описали популяционную модель Лотки — Вольтерры, не прибегая к дифурам) Проблема в том, что при изменении параметров среды система может легко потерять устойчивость.
Спасибо за статью, изложено структурированно! Но все же в вашей аргументации нахожу нестыковки.
Однако, возникают ситуации, что по одному ключу регистрируется список зависимостей с помощью опции провайдера multi: true. Такой подход подразумевает, что мне нужно как-то получать конкретную реализацию из списка.
Все-таки multi существует для того, когда есть задача получить по ключу именно массив, а не одну сущность. В доке Ангуляра это тоже обговорено, правда, косвенно, через пример. В итоге multi: true и "получить конкретную реализацию из списка" это противоположные по смыслу вещи.
Под один токен регистрируются разные реализации одного контракта, которые могут подменяться в зависимости от состояния приложения
С этим я согласен, вот только multi тут ни к чему. Мы можем переопределять реализацию зависимости на разных уровнях иерархии компонентов, но выбрать, какую конкретно реализацию внедрить потребителю – задача DI-контейнера, а не пользовательского кода внутри компонента. Иначе вы частично на себя берете логику DI, что выглядит избыточно. Также при вашем подходе все реализации должны быть предоставлены на одном уровне в одном месте через provideMultiService, что в реальной жизни довольно редко встречается.
Если по какой-то причине вам в одном компоннете в разные моменты времени нужны сразу три разных реализации сервиса, как в примере выше, то почему бы просто не внедрить инжектор? В качестве ключа использовать не строки, а собственно токены – будь то типы сервисов или инстансы InjectionToken.
При такой реализации становится неясно, зачем нужны предложенные в статье обертки в виде менеджеров и т.д. Получать по ключу сущность – задача инжектора и он отлично с этим справляется.
Возможно, вы могли бы привести примеры задач из реальной жизни, где просто инжектора недостаточно и решениеч через менеджер действительно облегчило вам жизнь? Пока что трудно такое представить.
И еще вот интересно, что весь этот механизм завязан на глобальный стейт с мутируемыми глобальными переменными. Понятно, что на каком-то уровне кода красивая функциональная абстракция неизбежно заканчивается, но вот любопытно как это все хозяйство ведет себя при работе с микрофронтами. Особенно, если используются разные версии ангуляра. Получается, у каждого приложения свой граф...
Кажется, если бы сигналы были стандартизованы на уровне браузера, появилась бы возмождность красиво собирать бесшовные приложения из компонентов на разных фреймворках с минимальной просадкой перформанса.
В свое время уже успел прочитать доку Angular Signals Implementation, но от статьи все равно кайфанул! Когда речь заходит про сигналы, сразу приходит в голову картинка из статьи:
State of JavaScript frameworks 2024
Немного про детекцию изменений на вебе в 2024
Также подсвечу, что есть попытка закрепить успех сигналов в вебе на "официальном уровне" в виде веб-стандарта, но пока на stage 1.
Программа пишется на языке программирования, но в программном коде идентификаторы (переменные, функции, классы) в подавляющем большинстве коллективов принято называть именно на английском. Или, точнее сказать, используя лексику английского языка, поскольку правила грамматики, артикли и т.п. часто игнорируются.
Например, пишем
class IncomingCurrencyPayment {}, а неclass ВходящийВалютныйПлатеж {}Я готов принять, что ограниченный закрытый список неизменных ключевых слов языка типа
if,then– это заимствования из английского. Но, с моей точки зрения, было бы лукавством утверждать, что словоIncomingCurrencyPayment– это слово языка JavaScript, а не английское словосочетание. Можно сказать это, наплевав на семантику, но тогда вы утрачиваете полезное различение, затрудняя самому себе обсуждение вопроса.Поддержу. В моей практике разрабатывал приложение на тему статистики населения, где все крутилось вокруг 4-х гиганстких структур данных по 100+ полей с глубоким вложением. Все поля в ТЗ именовались в соответствии с нормативной базой в виде многословного русского канцелярита, но который всем знакомым с предметной областью знаком и понятен.
И мы для каждого поля пытались придумать перевод на английский. Перевод многих полей оказался неочевидный и/или непривлекательный. По итогу, пришел к выводу, что смысла этот перевод не принес никакого. Пожалуй, стоило оставлять кириллицу (ну или на худой конец транслит).
Позвольте с вами не согласиться: "поле" совсем не обязательно только про землю и злаки. Специально проверил в НКРЯ: "предметное поле" или "проблемное поле" не сильно уступают по частотности "предметной области". Правда, без прилагательного действительно глаз немного режет и отдает англицизмом
Ключевая мысль, пожалуй, в том, что фокус – это важный и ограниченный ресурс, который многие растрачивают по мелочам. А польза и применимость каждой конкретной практики неизбежно зависят от субъективных особенностей человека и условий труда.
Честный ответ в том, что далеко не все эти практики у меня получается стабильно поддерживать на ежедневной основе.
Часть внедрить было весьма легко. Например, нетрудно встать в 5 утра, когда я знаю, что это нужно, чтобы с кайфом провести время на корте для бадминтона)
Отключить уведомления тоже не сложно. Настроил режим "не беспокоить" по расписанию, затем отключил уведомления для всех приложений, которые любят слать рекламные пуши, и от всех чатов в телеграме, кроме важных личных чатов. Это несложное разовое действие, но большая инвестиция в фокус и свободное время в дальнейшем.
А вот начать бежалостно вычеркивать лишнее из todo-листа или перестать давать нереалистично короткие оценки сроков было куда сложнее. Не уверен, что есть универсальный способ все это внедрить, но он явно должен строиться вокруг поиска личной мотивации – через рефлексию и осознание ценности для себя, но вряд ли через самопринуждение.
Здорово, что смогли найти для себя что-то полезное!
Начинал промышленную разрбаотку как раз с .NET, а сейчас на TS пишу. Как же было приятно иметь дело с LINQ, где с любой коллекцией единообразная работа. А то в JS реально, как автор пишет, есть
.length, есть.size, есть, не дай бог, ещеObject.values({ /* ... */ }).length. А чтобы сумму по массиву посчитать приходиться городитьreduceкаждый раз... Ну либо lodash тащить...Это была версия на JS)
Судя по окладам, предположу, что в категорию веб-разработчиков попадают PHP-мастера и WordPress'еры
Простите, не удержался
SLA в 100% может быть даже вреден, поскольку достижим только при условии полного отсутствия изменений, а бизнес такой долго не живет. Да, тестировать фичи на проде в банке не стоит, но все-таки в любых изменениях нужно закладывать шанс на ошибку. Важно не 100% SLA, а наличие продуманных и отлаженных механизмов восстановления доступности для разных сценариев сбоев.
А я пришел сюда, чтобы почитать про лексер, парсер и AST, и тоже ушел несолоно хлебавши.
Имеется в виду обратная совместимость новой версии движка с кодом, написанном на старых версиях стандарта ECMAScript. В этом смысле внедрение нового синтаксиса`async/await` не является ломающим изменением и сохраняет обратную совместимость движка. Но старые браузеры, вы правы, тут совершенно ни при чем.
Ну вот я все равно не понял. Например, у нас подключен бот Renovate, который автоматом создал нам МР с обновлением версии дизайн-кита (скажем, Taiga UI). Прежде чем жмякнуть "Merge", хочется как-то убедиться, что этот апдейт не принес нам неожиданных изменений в верстке, цветах, шрифтах и т.д. Даже при самой аккуратной работе создателя библиотеки, он едва ли сможет гарантировать, что изменения, вносимые в библиотеку не приведут к проблемам ни у одного из потребителей.
Вот недавно у нас как раз был кейс, когда в UI-кит добавили отдельную цветовую тему для мобильных устройств. Так вот у нас из-за того, что тема подключалась в приложение не так, как того стала требовать новая версия либы, мобильные цвета стали применяться и на десктопе. И если б не скриншоты, мы легко могли пропустить эту проблему на прод.
К тому же иногда, изменения вносятся умышленно. Например, меняется размер скруглений у элементов. Разумеется, мы хотим увидеть, как выглядит новый вариант нашего приложения, чем отличается от предыдущего и провести дизайн-ревью. Делать это со скриншотами явно легче, чем руками регрессить приложение на тестовом контуре.
Детально не сравнивал, но этот вариант перевода, на первый взгляд, выглядит лучше.
Тут вы не совсем правы. Просто для примера, Т-Банк разрабатывает и продает чисто IT-шные продукты для рынка: Sage, Statist, Unidraw. Крупные банки являются драйверами развития нейросетевых технологий в России – причем как в продуктовом внедрении, так и в рисерче. Даже в опенсорс выкладывают.
Крупные компании РФ (в том числе известные в первую очередь как банки) стало не так-то легко классифицировать, потому что часто это холдинги с целым зонтиком юрлиц и направлений, включая IT. Сбер, например, участвует в разработке "программно-аппаратных" беспилотных тракторов.
P.S. Да, я работаю в Т, поэтому про него так много и пишу, но он такой не один)
Вы только что популярно описали популяционную модель Лотки — Вольтерры, не прибегая к дифурам) Проблема в том, что при изменении параметров среды система может легко потерять устойчивость.
Спасибо за статью, изложено структурированно! Но все же в вашей аргументации нахожу нестыковки.
Все-таки
multiсуществует для того, когда есть задача получить по ключу именно массив, а не одну сущность. В доке Ангуляра это тоже обговорено, правда, косвенно, через пример. В итогеmulti: trueи "получить конкретную реализацию из списка" это противоположные по смыслу вещи.С этим я согласен, вот только
multiтут ни к чему. Мы можем переопределять реализацию зависимости на разных уровнях иерархии компонентов, но выбрать, какую конкретно реализацию внедрить потребителю – задача DI-контейнера, а не пользовательского кода внутри компонента. Иначе вы частично на себя берете логику DI, что выглядит избыточно. Также при вашем подходе все реализации должны быть предоставлены на одном уровне в одном месте черезprovideMultiService, что в реальной жизни довольно редко встречается.Если по какой-то причине вам в одном компоннете в разные моменты времени нужны сразу три разных реализации сервиса, как в примере выше, то почему бы просто не внедрить инжектор? В качестве ключа использовать не строки, а собственно токены – будь то типы сервисов или инстансы
InjectionToken.При такой реализации становится неясно, зачем нужны предложенные в статье обертки в виде менеджеров и т.д. Получать по ключу сущность – задача инжектора и он отлично с этим справляется.
Возможно, вы могли бы привести примеры задач из реальной жизни, где просто инжектора недостаточно и решениеч через менеджер действительно облегчило вам жизнь? Пока что трудно такое представить.
И еще вот интересно, что весь этот механизм завязан на глобальный стейт с мутируемыми глобальными переменными. Понятно, что на каком-то уровне кода красивая функциональная абстракция неизбежно заканчивается, но вот любопытно как это все хозяйство ведет себя при работе с микрофронтами. Особенно, если используются разные версии ангуляра. Получается, у каждого приложения свой граф...
Кажется, если бы сигналы были стандартизованы на уровне браузера, появилась бы возмождность красиво собирать бесшовные приложения из компонентов на разных фреймворках с минимальной просадкой перформанса.
В свое время уже успел прочитать доку Angular Signals Implementation, но от статьи все равно кайфанул! Когда речь заходит про сигналы, сразу приходит в голову картинка из статьи:
State of JavaScript frameworks 2024
Также подсвечу, что есть попытка закрепить успех сигналов в вебе на "официальном уровне" в виде веб-стандарта, но пока на stage 1.