Звучит правдоподобно. Если честно, вообще не представляю структуру рынка средств производства в РФ, интересно было бы почитать о ней какой-то обзор. А что китайцы, неужели они не делают свои аналоги концентратов, манжет и прочего?
Это зависит от структуры потребления. Жилье, еда и прочие товары / услуги повседневного спроса производятся по большей части внутри РФ. Предметы, которые условно можно отнести к "роскоши" (более дорогая еда, электроника и т. д.) - обычно импортные.
Да, зарплаты пока под большим вопросом. Я могу придумать аргументы и за то, что они сильно упадут, и за то, что вырастут, и за то, что останутся прежними. Пока не представляю, как все в этом плане пойдет дальше.
Судя по всему, повысится спрос на средства, повышающие утилизацию имеющегося железа. Популярность скриптовых ЯП уменьшится в пользу более эффективных компилируемых типа Rust или С++. Во некоторых случаях это может привести к сокращению потребления вычислительных ресурсов в десятки-сотни раз. Также потребуется создавать внутренние аналоги популярным зарубежным сервисам / ПО. Это все надо кому-то делать, так что рабочие места для айтишников, вероятно, никуда не денутся.
Ага, я специально вынес именно этот вопрос из общей топики, т.к. от его решения по сути и зависит надежность всей системы. Золотых пилюль у меня, увы, нет. Просто я считаю полезным отделить этот вопрос от общей абстракции ЭС и решать изолировано с максимально возможным приближением к идеалу.
Мне в этом контексте нравится идея классических экспертных систем.
У экспертной системы есть факты и есть правила. Любое изменение факта является триггером для применения связанных с этим типом фактов правил. Каждое применение правила порождает или изменяет какой-то из фактов, что в свою очередь может снова спровоцировать срабатывание нового правила и так далее. При этом правила могут быть как атомарными (если X => Y), так и составными (если X и Z => Y) — такую возможность должен поддерживать ваш DSL.
К экспертной системе вы можете подключать внешних агентов, которые будут:
Вводить в систему новые факты или изменения существующих.
Реагировать на объявление новых фактов или изменения старых какими-то действиями вовне ЭС, например вызовами каких-то функций-обработчиков.
С таким подходом вы можете изолировать друг от друга 3 разных части обработки стейтов: программный код, код, описывающий правила, и факты как сущности. Но главное — становятся доступны главные киллер-фичи ЭС, например возможность оптимизировать число операций за счет "упреждающих" проходов по графу правил или получить исчерпывающий отчет о причинах каждого принятого системой решения (такие отчеты можно потом логировать, что упрощает дебаг).
При этом система выглядит практически бесконечно масштабируемой. Код вместе с правилами можно скопировать на любое число инстансов. Остаются факты, набор которых должен поддерживаться в актуальном состоянии на всех инстансах ЭС. Хорошая новость: факт — это обычное K-V (у него всегда есть идентификатор и значение), а значит можно эффективно использовать нереляционное хранилище в качестве централизованного источника истины для фактов. Остается задача, как сделать так, чтобы каждый новый входной триггер провоцировал срабатывание правил строго на одном инстансе ЭС, но это уже дело техники.
Интересно. Я правильно понял, что есть DSL для как бы автогенерации грубых обработчиков, но можно писать ручками и более умные, которые могут ходить в базу и т. д.?
Ну кстати, не так уж и невозможно. В тех же госуслугах реально ценны только данные, хранящиеся где-то глубоко на бекенде. Вполне можно со стороны государства предоставить API к этим данным и позволить любым желающим пилить к ним UI: сайты, мобильные приложения, голосовые сценарии и т. д. Это первый слой конкуренции. Второй — непосредственно хранение и интерфейс к данным. Тут тоже могли бы конкурировать разные организации на предмет того, кто сможет написать более нагрузоустойчивую реализацию за меньшие деньги. Третий слой возможной конкуренции — механизмы безопасности для первых двух. Условно, государство должно обеспечить конкурентные условия для фирм / людей, которые способны найти уязвимости в элементах сервиса.
Статья главным образом не о логгере, а о том, как в принципе можно сделать настройки чего угодно изменяемыми в рантайме, на примере логгера. Но я попробую в ближайшее время написать статью-сравнение, уже целенаправленно о логгере.
В принципе подход с "не изменять, а копировать" в многопоточке валидный и часто решает много проблем, но для меня не очевидно, как именно он применим в данном случае.
Я в курсе про нее. Она мне не нравится по ряду причин, начиная с того, как написан и декомпозирован код, как там все прибито гвоздями в архитектурном плане.
Но главная причина написания собственного фреймворка - это желание создать собственную мощную систему декораторов логирования. Ничего подобного я до сих пор не встречал нигде, и в loguru этого тоже нет. Практически все существующие логгинг-либы так или иначе наследуют уродливый интерфейс стандартного logging, я же сделал систему, которая, на мой взгляд, сильно удобнее. Конструкция ядра фреймворка здесь вторична, но раз так уж вышло, что там нашлось что-то интересное - решил об этом написать.
Когда-нибудь я напишу статью про свой фреймворк и чем он лучше остальных, но сегодня это не совсем по теме.
Не, статья немного о другом. Очередь, движок и прочее используются лишь как пример отработки коллбека при изменении одного пункта настроек. Как настройки за счет защищенных локами коллбеков становятся интерактивными, а не задаются жестко при старте программы. Объект настроек никуда не передается через очередь. Наоборот, это его все отовсюду дергают.
Привет. Мне нравятся эти улучшения. Первое точно затащу к себе, насчет второго есть нюанс.
Я не стал включать это статью, т.к. счел мелкой подробностью, которыми ее не стоит загромождать, но в доке к Queue.empty() есть приписка:
Return True if the queue is empty, False otherwise. If empty() returns True it doesn’t guarantee that a subsequent call to put() will not block. Similarly, if empty() returns False it doesn’t guarantee that a subsequent call to get() will not block.
То есть метод empty() на самом деле не точный и дает примерный результат. Т.к. моя цель - не потерять ни одного лога, я не могу закончить работу и выйти из цикла, пока не буду точно убежден, что очередь пуста. Да, на это уйдет еще один time_quant, но это цена гарантии.
Хороша, но не хочу тащить такую громадную зависимость только ради валидации нескольких полей. Валидация здесь - маленький кусок общей задачи. Отсутствие внешних зависимостей - одна из главных фич проекта.
Между моим фреймворком и logging слишком много отличий, чтобы здесь их все перечислить. Конкретно в вопросе неблокирующего движка главных отличий 2: у меня можно изменить количество воркеров в рантайме в любой момент, не потеряв ни одного лога, или даже безболезненно сменить движок; у меня есть защита при завершении программы от потери логов, оставшихся в очереди.
Закрывать рублевые кредиты сейчас — самая глупая идея из возможных. Рубль обесценился, по многим ранее взятым кредитам сейчас ставки ниже инфляции.
Звучит правдоподобно. Если честно, вообще не представляю структуру рынка средств производства в РФ, интересно было бы почитать о ней какой-то обзор. А что китайцы, неужели они не делают свои аналоги концентратов, манжет и прочего?
Это зависит от структуры потребления. Жилье, еда и прочие товары / услуги повседневного спроса производятся по большей части внутри РФ. Предметы, которые условно можно отнести к "роскоши" (более дорогая еда, электроника и т. д.) - обычно импортные.
Да, зарплаты пока под большим вопросом. Я могу придумать аргументы и за то, что они сильно упадут, и за то, что вырастут, и за то, что останутся прежними. Пока не представляю, как все в этом плане пойдет дальше.
Судя по всему, повысится спрос на средства, повышающие утилизацию имеющегося железа. Популярность скриптовых ЯП уменьшится в пользу более эффективных компилируемых типа Rust или С++. Во некоторых случаях это может привести к сокращению потребления вычислительных ресурсов в десятки-сотни раз. Также потребуется создавать внутренние аналоги популярным зарубежным сервисам / ПО. Это все надо кому-то делать, так что рабочие места для айтишников, вероятно, никуда не денутся.
Это где такие геймпассы за 1к рублей в год раздают?
Ага, я специально вынес именно этот вопрос из общей топики, т.к. от его решения по сути и зависит надежность всей системы. Золотых пилюль у меня, увы, нет. Просто я считаю полезным отделить этот вопрос от общей абстракции ЭС и решать изолировано с максимально возможным приближением к идеалу.
Мне в этом контексте нравится идея классических экспертных систем.
У экспертной системы есть факты и есть правила. Любое изменение факта является триггером для применения связанных с этим типом фактов правил. Каждое применение правила порождает или изменяет какой-то из фактов, что в свою очередь может снова спровоцировать срабатывание нового правила и так далее. При этом правила могут быть как атомарными (если X => Y), так и составными (если X и Z => Y) — такую возможность должен поддерживать ваш DSL.
К экспертной системе вы можете подключать внешних агентов, которые будут:
Вводить в систему новые факты или изменения существующих.
Реагировать на объявление новых фактов или изменения старых какими-то действиями вовне ЭС, например вызовами каких-то функций-обработчиков.
С таким подходом вы можете изолировать друг от друга 3 разных части обработки стейтов: программный код, код, описывающий правила, и факты как сущности. Но главное — становятся доступны главные киллер-фичи ЭС, например возможность оптимизировать число операций за счет "упреждающих" проходов по графу правил или получить исчерпывающий отчет о причинах каждого принятого системой решения (такие отчеты можно потом логировать, что упрощает дебаг).
При этом система выглядит практически бесконечно масштабируемой. Код вместе с правилами можно скопировать на любое число инстансов. Остаются факты, набор которых должен поддерживаться в актуальном состоянии на всех инстансах ЭС. Хорошая новость: факт — это обычное K-V (у него всегда есть идентификатор и значение), а значит можно эффективно использовать нереляционное хранилище в качестве централизованного источника истины для фактов. Остается задача, как сделать так, чтобы каждый новый входной триггер провоцировал срабатывание правил строго на одном инстансе ЭС, но это уже дело техники.
Интересно. Я правильно понял, что есть DSL для как бы автогенерации грубых обработчиков, но можно писать ручками и более умные, которые могут ходить в базу и т. д.?
А DSL поддерживает динамические стейты?
А вывод-то какой из статьи? VR-обучение сварке — хорошо или плохо?
Ну кстати, не так уж и невозможно. В тех же госуслугах реально ценны только данные, хранящиеся где-то глубоко на бекенде. Вполне можно со стороны государства предоставить API к этим данным и позволить любым желающим пилить к ним UI: сайты, мобильные приложения, голосовые сценарии и т. д. Это первый слой конкуренции. Второй — непосредственно хранение и интерфейс к данным. Тут тоже могли бы конкурировать разные организации на предмет того, кто сможет написать более нагрузоустойчивую реализацию за меньшие деньги. Третий слой возможной конкуренции — механизмы безопасности для первых двух. Условно, государство должно обеспечить конкурентные условия для фирм / людей, которые способны найти уязвимости в элементах сервиса.
Статья главным образом не о логгере, а о том, как в принципе можно сделать настройки чего угодно изменяемыми в рантайме, на примере логгера. Но я попробую в ближайшее время написать статью-сравнение, уже целенаправленно о логгере.
Да, это очень похоже на правду. Пораскуриваю еще, и если не найду проблем - тоже утащу себе.
В принципе подход с "не изменять, а копировать" в многопоточке валидный и часто решает много проблем, но для меня не очевидно, как именно он применим в данном случае.
Я в курсе про нее. Она мне не нравится по ряду причин, начиная с того, как написан и декомпозирован код, как там все прибито гвоздями в архитектурном плане.
Но главная причина написания собственного фреймворка - это желание создать собственную мощную систему декораторов логирования. Ничего подобного я до сих пор не встречал нигде, и в loguru этого тоже нет. Практически все существующие логгинг-либы так или иначе наследуют уродливый интерфейс стандартного logging, я же сделал систему, которая, на мой взгляд, сильно удобнее. Конструкция ядра фреймворка здесь вторична, но раз так уж вышло, что там нашлось что-то интересное - решил об этом написать.
Когда-нибудь я напишу статью про свой фреймворк и чем он лучше остальных, но сегодня это не совсем по теме.
Не, статья немного о другом. Очередь, движок и прочее используются лишь как пример отработки коллбека при изменении одного пункта настроек. Как настройки за счет защищенных локами коллбеков становятся интерактивными, а не задаются жестко при старте программы. Объект настроек никуда не передается через очередь. Наоборот, это его все отовсюду дергают.
Это какое?
Привет. Мне нравятся эти улучшения. Первое точно затащу к себе, насчет второго есть нюанс.
Я не стал включать это статью, т.к. счел мелкой подробностью, которыми ее не стоит загромождать, но в доке к Queue.empty() есть приписка:
То есть метод empty() на самом деле не точный и дает примерный результат. Т.к. моя цель - не потерять ни одного лога, я не могу закончить работу и выйти из цикла, пока не буду точно убежден, что очередь пуста. Да, на это уйдет еще один time_quant, но это цена гарантии.
Хороша, но не хочу тащить такую громадную зависимость только ради валидации нескольких полей. Валидация здесь - маленький кусок общей задачи. Отсутствие внешних зависимостей - одна из главных фич проекта.
Между моим фреймворком и logging слишком много отличий, чтобы здесь их все перечислить. Конкретно в вопросе неблокирующего движка главных отличий 2: у меня можно изменить количество воркеров в рантайме в любой момент, не потеряв ни одного лога, или даже безболезненно сменить движок; у меня есть защита при завершении программы от потери логов, оставшихся в очереди.