#ФедиЧитальня

ISBN: 978-5-98062-072-1
Книга: Объекты желания. Дизайн и общество с 1750 года.
Автор: Адриан Форти
Издательство: Студия Артемия Лебедева
Год: 1986, перевод - 2013
Жанр: Маркетинг
Объем: 456 с.
Формат: PDF A4
Язык: RU

Бэкграунд: Не требуется
Доступ: а хрен знает, даже на сайте издательства нет в наличии

Предложил: @strizhechenko

Мои посты здесь автоматически удаляются, но я раз в неделю собираю их в статью в персистентном хранилище: https://strizhechenko.github.io/2023/08/21/design.html

//cc @fflitclub

#федичитальня #postgresql #postgresql15

Сортировка по индексу.

#Btree #индексы можно и для сортировки за O(n) использовать без буферизации всех строк где-либо. Но с неопределёнными значениями и порядком сортировки есть нюанс - положение их в индексе задаётся при создании и, если запрашиваемое положение отличается, то индекс не может быть использован.

Вообще странно, что не воткнули костыль для простейших случаев, если nulls не там, просто читаем индекс с другого конца, до тех пор, пока не наткнёмся на не #null, после чего начнём читать индекс так, как изначально и планировалось, до тех пор, пока не на кнёмся на null, который послужит нам эдаким EOF. Сложность чтения бы сохранилась линейной, всего пару переменных и ифников для стейт-контрола добавить. Не думаю, что это был бы значимый оверхед.

#Федичитальня #PostgreSQL заметил, что планировщик учитывает только CPU и объём дискового чтения/записи. А вот выделение памяти он не учитывает. Это фишечка встроенного мемори-менеджера, который заранее выделяет пул, а дальше играется с realloc'ами и прочим? Или нет выделения памяти кроме чтения с диска, а в его оценку память уже заложена?

#DTM чот полистал доклады и прочее (в книге пока не добрался). Это что выходит, люди с распределёнными транзакциями в пределах одной БД одного сервиса ебутся? Я-то думал это гемор межсервисного взаимодействия, затыкаемый служебными колонками с FSM и таймерами для реентерабельности, а там всего-то в разных шардах надо две строчки сперва заблокировать, обновить и сделать видимыми одновременно.

Почитал маркетинговую статейку, продающую BPM систему. И основной её поинт в безусловной ценности формализации процессов. Хер с BPM и организациями, я это на себе испытывал. CAPEX расходов много – наблюдение за текущим процессом, анализ, формализация – это очевидное. А вот OPEX, помимо очевидных на "следование" процессу (я про расходы, на которые, при перевешивании доходов, любят закрыть глаза, а не про сальдо) имеет ещё и неочевидные, на "отступление" от процесса. В отличии от интуитивного принятия решения, при очевидной, казалось бы, неоптимальности выбора, тактика начинает тормозиться стратегией, которая противоречит. Мало того, что возрастает шанс "просто действовать согласно процессу" и принять ущерб, заложенный стратегией, так ещё и отклонение от стратегии становится дороже, потому что надо обдумать мысли вида "но я же принял решение ...".

А про свой опыт, я года полтора жил по поминутно расписанному распорядку дня. Мне сильно не хватает дисциплины, я рассеянный чувак, это подпитывается работой, требующей фокусировки на чём-то одном, поэтому сгружение рутины, планирования и прогнозирования на внешний носитель было жизненно необходимо, чтобы:
1. банально не засраться,
2. быть способным ответить на вопрос "а когда ты ..." хотя бы с 80% погрешностью и не бросаться с одного незаконченного дела на другое.

По используемым технологиям, не суть, суть в подходе и он мало чем от тех же BPM систем. И вот по этому подходу я скучаю и пытаюсь его воскресить, но на других рельсах (было гугл-таблицы, стало python+web). Но на долгой дистанции он заёбывает! Но его отсутствие и бардак в делах тоже заёбывает! И вот как маятник мотаюсь туда сюда. В случае с организациями история становится сложнее - оценить влияние внедрения в краткосроке тяжело, в долгосроке - долго. Ещё интереснее было бы почитать про опыт отказа организации от формализации процессов с выхлопом от облегчения. Либо про смену степени формализации, без полного отказа.

Почитал маркетинговую статейку, продающую BPM систему. И основной её поинт в безусловной ценности формализации процессов. Хер с BPM и организациями, я это на себе испытывал. CAPEX расходов много – наблюдение за текущим процессом, анализ, формализация – это очевидное. А вот OPEX, помимо очевидных на "следование" процессу (я про расходы, на которые, при перевешивании доходов, любят закрыть глаза, а не про сальдо) имеет ещё и неочевидные, на "отступление" от процесса. В отличии от интуитивного принятия решения, при очевидной, казалось бы, неоптимальности выбора, тактика начинает тормозиться стратегией, которая противоречит. Мало того, что возрастает шанс "просто действовать согласно процессу" и принять ущерб, заложенный стратегией, так ещё и отклонение от стратегии становится дороже, потому что надо обдумать мысли вида "но я же принял решение ...".

А про свой опыт, я года полтора жил по поминутно расписанному распорядку дня. Мне сильно не хватает дисциплины, я рассеянный чувак, это подпитывается работой, требующей фокусировки на чём-то одном, поэтому сгружение рутины, планирования и прогнозирования на внешний носитель было жизненно необходимо, чтобы:
1. банально не засраться,
2. быть способным ответить на вопрос "а когда ты ..." хотя бы с 80% погрешностью и не бросаться с одного незаконченного дела на другое.
По используемым технологиям, не суть, суть в подходе и он мало чем от тех же BPM систем. И вот по этому подходу я скучаю и пытаюсь его воскресить, но на других рельсах (было гугл-таблицы, стало python+web).