Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Keeping a Postgres queue healthy
Статьи, связанные с реализацией очередей на постгресе, упоминались в канале еще шесть лет назад. Сегодня текст, который фокусируется на перфомансе очередей в инстансе постгреса, где содержатся основные данные.
Начинается текст с описания проблемы: берем пг, в него пихаем очередь, а что делать с нагрузкой в таком случае не понятно. Причем, паттерн поведения в очереди строится вокруг того, что данные пишутся, единоразово читаются. А после, старые данные, необходимо удалить, чтобы база не распухала. Вот тут и начинается проблема, так как появляются dead tuples, т.е. записи, которые для базы «удалены» (запросы игнорируют данные), но в реальности, данные удалятся только после VACUUM. Далее приводится пример очереди jobs, состоящей из 4 колонок (
pk, json, status и run_at). И подробно объясняется проблема dead tuples, которую автор симулирует. После объясняется работа вакуума и приводится список решений, которые помогут в удалении «мертвых» данных.#psql
—————————————
The Math of Why You Can't Focus at Work
В пятничных ссылках редко встречаются тексты связанные с продуктивностью. Связанно это с тем, что 99% подобных статей либо «сео» статьи, либо банальщина вокруг очередной настройки obsidian или todoist. Текст выше крутится вокруг относительно «капитанской» идеи: «меньше прерывания, больше сфокусированной работы, больше удовлетворения работой». Но вы читаете эту подводку из-за того, что автор решил доказать это утверждение используя мат модель, что редкость для подобных статей.
Начинается статья с постановки проблемы, связанной с прерываниями. Для этого показывается «хороший» день, когда прерываний мало и в наличии 2 блока на 2+ часа для «глубокой» работы. А также показывается «плохой» день, где времени на «глубокую» работу — меньше двух часов в сумме. Из этого, автор выделяет три главных фактора «хорошего» дня: сколько раз в час прерывают, сколько времени требуется на восстановление концентрации, минимальная продолжительность блока осмысленной работы. И тут же появляется мат модель, которую автор визуализируют. А самое интересное начинается, когда берутся данные о количестве прерываний из исследований, а в визуализации нет времени на работу. Во второй части статьи автор делится советами, как улучшить ситуацию (с проверкой через модель).
#productivity
—————————————
Какой минимум симптомов нужен врачу для постановки диагноза
Не смотрите на название статьи, текст о теории грубых множеств и о том, как определить «значимые» факторы из выборки. Просто для примера автор решил определить важные симптомы для определения диагноза болезни.
Текст начинается с истории появления теории грубых множеств, основанной на теориях вероятности и нечеткой логике. А главная идея вертится вокруг согласованности, т.е. ситуации, когда нет объектов с одинаковыми признаками или симптомами, но разными «диагнозами». Причем, размер выборки не важен, даже 10 строк в таблице хватит. Кроме согласованности, придется еще разобраться с вектором значимости и суперредуктом и редуктом. Далее, на примере симптомов и болезни, описывается алгоритм поиска важных признаков. А в конце приводится пример кода на julia.
Если говорить о применимости теории в IT, то первое о чем подумал, когда читал текст — было бы интересно воспользоваться теорией для анализа постмортемов. Т.е. берем происшествия, выделяем признаки, после чего получаем вектор значимости для признаков. А на «важные» признаки тратим больше ресурса на проверку в релизах и ежедневной работе.
#data_analysis