Стоило упомянуть, что есть библиотеки, реализующие уже готовые абстракции над разными видами кэширования. Чтобы сменить in-memory на redis или memcached, не нужно переписывать декораторы во всем проекте, достаточно в одном месте изменить бекенд такой библиотеки. Как пример — aiocache.
Звучит правдоподобно. Если честно, вообще не представляю структуру рынка средств производства в РФ, интересно было бы почитать о ней какой-то обзор. А что китайцы, неужели они не делают свои аналоги концентратов, манжет и прочего?
Это зависит от структуры потребления. Жилье, еда и прочие товары / услуги повседневного спроса производятся по большей части внутри РФ. Предметы, которые условно можно отнести к "роскоши" (более дорогая еда, электроника и т. д.) - обычно импортные.
Да, зарплаты пока под большим вопросом. Я могу придумать аргументы и за то, что они сильно упадут, и за то, что вырастут, и за то, что останутся прежними. Пока не представляю, как все в этом плане пойдет дальше.
Судя по всему, повысится спрос на средства, повышающие утилизацию имеющегося железа. Популярность скриптовых ЯП уменьшится в пользу более эффективных компилируемых типа Rust или С++. Во некоторых случаях это может привести к сокращению потребления вычислительных ресурсов в десятки-сотни раз. Также потребуется создавать внутренние аналоги популярным зарубежным сервисам / ПО. Это все надо кому-то делать, так что рабочие места для айтишников, вероятно, никуда не денутся.
Ага, я специально вынес именно этот вопрос из общей топики, т.к. от его решения по сути и зависит надежность всей системы. Золотых пилюль у меня, увы, нет. Просто я считаю полезным отделить этот вопрос от общей абстракции ЭС и решать изолировано с максимально возможным приближением к идеалу.
Мне в этом контексте нравится идея классических экспертных систем.
У экспертной системы есть факты и есть правила. Любое изменение факта является триггером для применения связанных с этим типом фактов правил. Каждое применение правила порождает или изменяет какой-то из фактов, что в свою очередь может снова спровоцировать срабатывание нового правила и так далее. При этом правила могут быть как атомарными (если X => Y), так и составными (если X и Z => Y) — такую возможность должен поддерживать ваш DSL.
К экспертной системе вы можете подключать внешних агентов, которые будут:
Вводить в систему новые факты или изменения существующих.
Реагировать на объявление новых фактов или изменения старых какими-то действиями вовне ЭС, например вызовами каких-то функций-обработчиков.
С таким подходом вы можете изолировать друг от друга 3 разных части обработки стейтов: программный код, код, описывающий правила, и факты как сущности. Но главное — становятся доступны главные киллер-фичи ЭС, например возможность оптимизировать число операций за счет "упреждающих" проходов по графу правил или получить исчерпывающий отчет о причинах каждого принятого системой решения (такие отчеты можно потом логировать, что упрощает дебаг).
При этом система выглядит практически бесконечно масштабируемой. Код вместе с правилами можно скопировать на любое число инстансов. Остаются факты, набор которых должен поддерживаться в актуальном состоянии на всех инстансах ЭС. Хорошая новость: факт — это обычное K-V (у него всегда есть идентификатор и значение), а значит можно эффективно использовать нереляционное хранилище в качестве централизованного источника истины для фактов. Остается задача, как сделать так, чтобы каждый новый входной триггер провоцировал срабатывание правил строго на одном инстансе ЭС, но это уже дело техники.
Интересно. Я правильно понял, что есть DSL для как бы автогенерации грубых обработчиков, но можно писать ручками и более умные, которые могут ходить в базу и т. д.?
Любопытно. А есть ссылка с более подробным описанием / пример продукта с таким подходом?
А кошки и испытывают эмоции, близкие к человеческим. У всех млекопитающих базовое устройство мозга довольно похоже.
Так тот же Steam Deck уже практически подходит под это описание. 20-30 fps на высоких в Cyberpunk 2077.
У автора просто ORM нормальной не было.
Только что купил ее. Книжка великолепная, сокровище.
В ситуациях, когда нужно список чисел преобразовать, к примеру, в список квадратов, обычно лучше использовать генераторы.
То есть вместо:
Будет:
Такие преобразования могут наслаиваться друг на друга, а перевыделять каждый раз память под новые списки — дорого.
Мне кажется сомнительной идея при инициализации объекта создавать атрибут в классе, а не в объекте.
None — это не тип данных, а объект NoneType.
Стоило упомянуть, что есть библиотеки, реализующие уже готовые абстракции над разными видами кэширования. Чтобы сменить in-memory на redis или memcached, не нужно переписывать декораторы во всем проекте, достаточно в одном месте изменить бекенд такой библиотеки. Как пример — aiocache.
Закрывать рублевые кредиты сейчас — самая глупая идея из возможных. Рубль обесценился, по многим ранее взятым кредитам сейчас ставки ниже инфляции.
Звучит правдоподобно. Если честно, вообще не представляю структуру рынка средств производства в РФ, интересно было бы почитать о ней какой-то обзор. А что китайцы, неужели они не делают свои аналоги концентратов, манжет и прочего?
Это зависит от структуры потребления. Жилье, еда и прочие товары / услуги повседневного спроса производятся по большей части внутри РФ. Предметы, которые условно можно отнести к "роскоши" (более дорогая еда, электроника и т. д.) - обычно импортные.
Да, зарплаты пока под большим вопросом. Я могу придумать аргументы и за то, что они сильно упадут, и за то, что вырастут, и за то, что останутся прежними. Пока не представляю, как все в этом плане пойдет дальше.
Судя по всему, повысится спрос на средства, повышающие утилизацию имеющегося железа. Популярность скриптовых ЯП уменьшится в пользу более эффективных компилируемых типа Rust или С++. Во некоторых случаях это может привести к сокращению потребления вычислительных ресурсов в десятки-сотни раз. Также потребуется создавать внутренние аналоги популярным зарубежным сервисам / ПО. Это все надо кому-то делать, так что рабочие места для айтишников, вероятно, никуда не денутся.
Это где такие геймпассы за 1к рублей в год раздают?
Ага, я специально вынес именно этот вопрос из общей топики, т.к. от его решения по сути и зависит надежность всей системы. Золотых пилюль у меня, увы, нет. Просто я считаю полезным отделить этот вопрос от общей абстракции ЭС и решать изолировано с максимально возможным приближением к идеалу.
Мне в этом контексте нравится идея классических экспертных систем.
У экспертной системы есть факты и есть правила. Любое изменение факта является триггером для применения связанных с этим типом фактов правил. Каждое применение правила порождает или изменяет какой-то из фактов, что в свою очередь может снова спровоцировать срабатывание нового правила и так далее. При этом правила могут быть как атомарными (если X => Y), так и составными (если X и Z => Y) — такую возможность должен поддерживать ваш DSL.
К экспертной системе вы можете подключать внешних агентов, которые будут:
Вводить в систему новые факты или изменения существующих.
Реагировать на объявление новых фактов или изменения старых какими-то действиями вовне ЭС, например вызовами каких-то функций-обработчиков.
С таким подходом вы можете изолировать друг от друга 3 разных части обработки стейтов: программный код, код, описывающий правила, и факты как сущности. Но главное — становятся доступны главные киллер-фичи ЭС, например возможность оптимизировать число операций за счет "упреждающих" проходов по графу правил или получить исчерпывающий отчет о причинах каждого принятого системой решения (такие отчеты можно потом логировать, что упрощает дебаг).
При этом система выглядит практически бесконечно масштабируемой. Код вместе с правилами можно скопировать на любое число инстансов. Остаются факты, набор которых должен поддерживаться в актуальном состоянии на всех инстансах ЭС. Хорошая новость: факт — это обычное K-V (у него всегда есть идентификатор и значение), а значит можно эффективно использовать нереляционное хранилище в качестве централизованного источника истины для фактов. Остается задача, как сделать так, чтобы каждый новый входной триггер провоцировал срабатывание правил строго на одном инстансе ЭС, но это уже дело техники.
Деревья — подмножество графов.
Интересно. Я правильно понял, что есть DSL для как бы автогенерации грубых обработчиков, но можно писать ручками и более умные, которые могут ходить в базу и т. д.?
А DSL поддерживает динамические стейты?