Ну кстати, не так уж и невозможно. В тех же госуслугах реально ценны только данные, хранящиеся где-то глубоко на бекенде. Вполне можно со стороны государства предоставить 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: у меня можно изменить количество воркеров в рантайме в любой момент, не потеряв ни одного лога, или даже безболезненно сменить движок; у меня есть защита при завершении программы от потери логов, оставшихся в очереди.
Фреймворк универсален, может работать как в синхронном, так и в асинхронном режиме. Для отладки можно использовать синхронный. Асинхронный предназначен в первую очередь для повышения пиковой производительности высоконагруженных сервисов. Если к нам в моменте пришла куча запросов, мы сначала обработаем их, а уже потом в бэкграунде запишем куда-то логи.
Точность по времени там обычно не особо нужна, однако вы можете уменьшить разброс установкой лимита на максимальный размер очереди.
Последовательность именно записи часто тоже не принципиальна, если по самим логам можно восстановить последовательность событий. А так можно, поскольку каждое событие сопровождается временной меткой, соответственно при чтении или индексации логов в поисковой машине можно просто сортировать по этой метке.
В целом асинхронный движок для логов - это компромисс между пиковой производительностью сервиса и упомянутыми вами свойствами логов. Чем больше мы теряем в первом, тем больше приобретаем во втором, и наоборот. Здесь уже нужно выбирать по потребности, и фреймворк дает такую возможность.
Я пока фреймворк практически не использую, только пишу. Его текущая версия начинается с нуля, то есть на мой взгляд, он пока не готов для промышленного применения (хотя его уже можно использовать в каких-нибудь хобби-проектах).
Я думал об этом. Мне вариант со "Storage" не очень подходит, поскольку навевает ассоциации с персистентностью хранилища, а оно де-факто существует только в оперативной памяти. Между тем, одно из значений "Store" - это как раз "хранилище".
Пробовал, какие-то наметки даже в составе библиотеки есть (декоратор @inline). Но тогда (статья у меня пылилась где-то с весны) я его так и не довел до ума, а сейчас посмотрел на него и решил, что делать этого не буду и в статью включать не стану, т. к. очень сложно каким-то образом продемонстрировать, что эта оптимизация вообще что-то делает, поскольку в идеальном случае поведение функции не должно меняться вообще.
Я недавно купил дешевый дезинфектор для рук и был удивлен его возможностями. После того, как спирт высыхал, руки становились очень горькими, и делали горьким все, чего я касался. В результате я понял, как часто касался лица руками, т.к. постоянно чувствовал вкус горечи.
Для меня тоже не очевидно, что мешает игнорировать в рейтингах цитируемости работа самоссылки. Они отсеиваются одной строчкой кода.
Если сейчас кто-то из научного руководства посчитает высокий показатель самоссылок меткой недобросовестного ученого, под удар могут попасть вполне ни в чем не виновные сотрудники. Человек, скажем, может заниматься очень узкой проблематикой и быть таким одним на весь мир, ему просто не на кого будет ссылаться, кроме себя.
А вывод-то какой из статьи? VR-обучение сварке — хорошо или плохо?
Ну кстати, не так уж и невозможно. В тех же госуслугах реально ценны только данные, хранящиеся где-то глубоко на бекенде. Вполне можно со стороны государства предоставить API к этим данным и позволить любым желающим пилить к ним UI: сайты, мобильные приложения, голосовые сценарии и т. д. Это первый слой конкуренции. Второй — непосредственно хранение и интерфейс к данным. Тут тоже могли бы конкурировать разные организации на предмет того, кто сможет написать более нагрузоустойчивую реализацию за меньшие деньги. Третий слой возможной конкуренции — механизмы безопасности для первых двух. Условно, государство должно обеспечить конкурентные условия для фирм / людей, которые способны найти уязвимости в элементах сервиса.
Статья главным образом не о логгере, а о том, как в принципе можно сделать настройки чего угодно изменяемыми в рантайме, на примере логгера. Но я попробую в ближайшее время написать статью-сравнение, уже целенаправленно о логгере.
Да, это очень похоже на правду. Пораскуриваю еще, и если не найду проблем - тоже утащу себе.
В принципе подход с "не изменять, а копировать" в многопоточке валидный и часто решает много проблем, но для меня не очевидно, как именно он применим в данном случае.
Я в курсе про нее. Она мне не нравится по ряду причин, начиная с того, как написан и декомпозирован код, как там все прибито гвоздями в архитектурном плане.
Но главная причина написания собственного фреймворка - это желание создать собственную мощную систему декораторов логирования. Ничего подобного я до сих пор не встречал нигде, и в loguru этого тоже нет. Практически все существующие логгинг-либы так или иначе наследуют уродливый интерфейс стандартного logging, я же сделал систему, которая, на мой взгляд, сильно удобнее. Конструкция ядра фреймворка здесь вторична, но раз так уж вышло, что там нашлось что-то интересное - решил об этом написать.
Когда-нибудь я напишу статью про свой фреймворк и чем он лучше остальных, но сегодня это не совсем по теме.
Не, статья немного о другом. Очередь, движок и прочее используются лишь как пример отработки коллбека при изменении одного пункта настроек. Как настройки за счет защищенных локами коллбеков становятся интерактивными, а не задаются жестко при старте программы. Объект настроек никуда не передается через очередь. Наоборот, это его все отовсюду дергают.
Это какое?
Привет. Мне нравятся эти улучшения. Первое точно затащу к себе, насчет второго есть нюанс.
Я не стал включать это статью, т.к. счел мелкой подробностью, которыми ее не стоит загромождать, но в доке к Queue.empty() есть приписка:
То есть метод empty() на самом деле не точный и дает примерный результат. Т.к. моя цель - не потерять ни одного лога, я не могу закончить работу и выйти из цикла, пока не буду точно убежден, что очередь пуста. Да, на это уйдет еще один time_quant, но это цена гарантии.
Хороша, но не хочу тащить такую громадную зависимость только ради валидации нескольких полей. Валидация здесь - маленький кусок общей задачи. Отсутствие внешних зависимостей - одна из главных фич проекта.
Между моим фреймворком и logging слишком много отличий, чтобы здесь их все перечислить. Конкретно в вопросе неблокирующего движка главных отличий 2: у меня можно изменить количество воркеров в рантайме в любой момент, не потеряв ни одного лога, или даже безболезненно сменить движок; у меня есть защита при завершении программы от потери логов, оставшихся в очереди.
Фреймворк универсален, может работать как в синхронном, так и в асинхронном режиме. Для отладки можно использовать синхронный. Асинхронный предназначен в первую очередь для повышения пиковой производительности высоконагруженных сервисов. Если к нам в моменте пришла куча запросов, мы сначала обработаем их, а уже потом в бэкграунде запишем куда-то логи.
Точность по времени там обычно не особо нужна, однако вы можете уменьшить разброс установкой лимита на максимальный размер очереди.
Последовательность именно записи часто тоже не принципиальна, если по самим логам можно восстановить последовательность событий. А так можно, поскольку каждое событие сопровождается временной меткой, соответственно при чтении или индексации логов в поисковой машине можно просто сортировать по этой метке.
В целом асинхронный движок для логов - это компромисс между пиковой производительностью сервиса и упомянутыми вами свойствами логов. Чем больше мы теряем в первом, тем больше приобретаем во втором, и наоборот. Здесь уже нужно выбирать по потребности, и фреймворк дает такую возможность.
Я пока фреймворк практически не использую, только пишу. Его текущая версия начинается с нуля, то есть на мой взгляд, он пока не готов для промышленного применения (хотя его уже можно использовать в каких-нибудь хобби-проектах).
Я думал об этом. Мне вариант со "Storage" не очень подходит, поскольку навевает ассоциации с персистентностью хранилища, а оно де-факто существует только в оперативной памяти. Между тем, одно из значений "Store" - это как раз "хранилище".
Может вам статью об этом написать? Красивое.
Пробовал, какие-то наметки даже в составе библиотеки есть (декоратор @inline). Но тогда (статья у меня пылилась где-то с весны) я его так и не довел до ума, а сейчас посмотрел на него и решил, что делать этого не буду и в статью включать не стану, т. к. очень сложно каким-то образом продемонстрировать, что эта оптимизация вообще что-то делает, поскольку в идеальном случае поведение функции не должно меняться вообще.
По мне так дизайн ужасный. Вместо божественного минимализма непонятно что.
Я недавно купил дешевый дезинфектор для рук и был удивлен его возможностями. После того, как спирт высыхал, руки становились очень горькими, и делали горьким все, чего я касался. В результате я понял, как часто касался лица руками, т.к. постоянно чувствовал вкус горечи.
Если сейчас кто-то из научного руководства посчитает высокий показатель самоссылок меткой недобросовестного ученого, под удар могут попасть вполне ни в чем не виновные сотрудники. Человек, скажем, может заниматься очень узкой проблематикой и быть таким одним на весь мир, ему просто не на кого будет ссылаться, кроме себя.