ISBN: 978-5-98062-072-1 Книга: Объекты желания. Дизайн и общество с 1750 года. Автор: Адриан Форти Издательство: Студия Артемия Лебедева Год: 1986, перевод - 2013 Жанр: Маркетинг Объем: 456 с. Формат: PDF A4 Язык: RU
Бэкграунд: Не требуется Доступ: а хрен знает, даже на сайте издательства нет в наличии
ISBN: 978-5-98062-072-1 Книга: Объекты желания. Дизайн и общество с 1750 года. Автор: Адриан Форти Издательство: Студия Артемия Лебедева Год: 1986, перевод - 2013 Жанр: Маркетинг Объем: 456 с. Формат: PDF A4 Язык: RU
Бэкграунд: Не требуется Доступ: а хрен знает, даже на сайте издательства нет в наличии
#Btree#индексы можно и для сортировки за O(n) использовать без буферизации всех строк где-либо. Но с неопределёнными значениями и порядком сортировки есть нюанс - положение их в индексе задаётся при создании и, если запрашиваемое положение отличается, то индекс не может быть использован.
Вообще странно, что не воткнули костыль для простейших случаев, если nulls не там, просто читаем индекс с другого конца, до тех пор, пока не наткнёмся на не #null, после чего начнём читать индекс так, как изначально и планировалось, до тех пор, пока не на кнёмся на null, который послужит нам эдаким EOF. Сложность чтения бы сохранилась линейной, всего пару переменных и ифников для стейт-контрола добавить. Не думаю, что это был бы значимый оверхед.
#Btree#индексы можно и для сортировки за O(n) использовать без буферизации всех строк где-либо. Но с неопределёнными значениями и порядком сортировки есть нюанс - положение их в индексе задаётся при создании и, если запрашиваемое положение отличается, то индекс не может быть использован.
@strizhechenko не совсем понял, btree индекс же уже отсортирован, он просто умеет отдавать записи в правильном порядке, сортировки фактически не происходит или я глупенький и не понимаю о чём ты?
Решил потрогать траву^W #funkwhale в качестве платформы для публикации и сразу минус - URL страницы исполнителя: https://x.x/library/artists/18279/
Серьёзно? Вот ведь невероятные облегчение getByID в ORM и решение проблемы нескольких исполнителей с одинаковым названием, а. Возможности брендинга аж зашакаливают.
#Федичитальня#PostgreSQL заметил, что планировщик учитывает только CPU и объём дискового чтения/записи. А вот выделение памяти он не учитывает. Это фишечка встроенного мемори-менеджера, который заранее выделяет пул, а дальше играется с realloc'ами и прочим? Или нет выделения памяти кроме чтения с диска, а в его оценку память уже заложена?
#DTM чот полистал доклады и прочее (в книге пока не добрался). Это что выходит, люди с распределёнными транзакциями в пределах одной БД одного сервиса ебутся? Я-то думал это гемор межсервисного взаимодействия, затыкаемый служебными колонками с FSM и таймерами для реентерабельности, а там всего-то в разных шардах надо две строчки сперва заблокировать, обновить и сделать видимыми одновременно.
#Федичитальня#PostgreSQL заметил, что планировщик учитывает только CPU и объём дискового чтения/записи. А вот выделение памяти он не учитывает. Это фишечка встроенного мемори-менеджера, который заранее выделяет пул, а дальше играется с realloc'ами и прочим? Или нет выделения памяти кроме чтения с диска, а в его оценку память уже заложена?
@strizhechenko ну он учитывает. условно, ты выставил work_mem 64kb и делаешь сортировку по таблице, которая значительно больше, в эксплейне у тебя явно будет написано что сортировка происходит на Disk’е, а если work_mem адекватный, то там так и будет написано что сортировка в Memory
Почитал маркетинговую статейку, продающую BPM систему. И основной её поинт в безусловной ценности формализации процессов. Хер с BPM и организациями, я это на себе испытывал. CAPEX расходов много – наблюдение за текущим процессом, анализ, формализация – это очевидное. А вот OPEX, помимо очевидных на "следование" процессу (я про расходы, на которые, при перевешивании доходов, любят закрыть глаза, а не про сальдо) имеет ещё и неочевидные, на "отступление" от процесса. В отличии от интуитивного принятия решения, при очевидной, казалось бы, неоптимальности выбора, тактика начинает тормозиться стратегией, которая противоречит. Мало того, что возрастает шанс "просто действовать согласно процессу" и принять ущерб, заложенный стратегией, так ещё и отклонение от стратегии становится дороже, потому что надо обдумать мысли вида "но я же принял решение ...".
А про свой опыт, я года полтора жил по поминутно расписанному распорядку дня. Мне сильно не хватает дисциплины, я рассеянный чувак, это подпитывается работой, требующей фокусировки на чём-то одном, поэтому сгружение рутины, планирования и прогнозирования на внешний носитель было жизненно необходимо, чтобы: 1. банально не засраться, 2. быть способным ответить на вопрос "а когда ты ..." хотя бы с 80% погрешностью и не бросаться с одного незаконченного дела на другое.
По используемым технологиям, не суть, суть в подходе и он мало чем от тех же BPM систем. И вот по этому подходу я скучаю и пытаюсь его воскресить, но на других рельсах (было гугл-таблицы, стало python+web). Но на долгой дистанции он заёбывает! Но его отсутствие и бардак в делах тоже заёбывает! И вот как маятник мотаюсь туда сюда. В случае с организациями история становится сложнее - оценить влияние внедрения в краткосроке тяжело, в долгосроке - долго. Ещё интереснее было бы почитать про опыт отказа организации от формализации процессов с выхлопом от облегчения. Либо про смену степени формализации, без полного отказа.
Почитал маркетинговую статейку, продающую BPM систему. И основной её поинт в безусловной ценности формализации процессов. Хер с BPM и организациями, я это на себе испытывал. CAPEX расходов много – наблюдение за текущим процессом, анализ, формализация – это очевидное. А вот OPEX, помимо очевидных на "следование" процессу (я про расходы, на которые, при перевешивании доходов, любят закрыть глаза, а не про сальдо) имеет ещё и неочевидные, на "отступление" от процесса. В отличии от интуитивного принятия...
@strizhechenko Про формализацию - попробуй почитать про холакратию. Не совсем по теме, но в примерах реализации есть интересные темы замены формализации неким подобием социальных сетей.
Почитал маркетинговую статейку, продающую BPM систему. И основной её поинт в безусловной ценности формализации процессов. Хер с BPM и организациями, я это на себе испытывал. CAPEX расходов много – наблюдение за текущим процессом, анализ, формализация – это очевидное. А вот OPEX, помимо очевидных на "следование" процессу (я про расходы, на которые, при перевешивании доходов, любят закрыть глаза, а не про сальдо) имеет ещё и неочевидные, на "отступление" от процесса. В отличии от интуитивного принятия решения, при очевидной, казалось бы, неоптимальности выбора, тактика начинает тормозиться стратегией, которая противоречит. Мало того, что возрастает шанс "просто действовать согласно процессу" и принять ущерб, заложенный стратегией, так ещё и отклонение от стратегии становится дороже, потому что надо обдумать мысли вида "но я же принял решение ...".
А про свой опыт, я года полтора жил по поминутно расписанному распорядку дня. Мне сильно не хватает дисциплины, я рассеянный чувак, это подпитывается работой, требующей фокусировки на чём-то одном, поэтому сгружение рутины, планирования и прогнозирования на внешний носитель было жизненно необходимо, чтобы: 1. банально не засраться, 2. быть способным ответить на вопрос "а когда ты ..." хотя бы с 80% погрешностью и не бросаться с одного незаконченного дела на другое. По используемым технологиям, не суть, суть в подходе и он мало чем от тех же BPM систем. И вот по этому подходу я скучаю и пытаюсь его воскресить, но на других рельсах (было гугл-таблицы, стало python+web).
Почитал маркетинговую статейку, продающую BPM систему. И основной её поинт в безусловной ценности формализации процессов. Хер с BPM и организациями, я это на себе испытывал. CAPEX расходов много – наблюдение за текущим процессом, анализ, формализация – это очевидное. А вот OPEX, помимо очевидных на "следование" процессу (я про расходы, на которые, при перевешивании доходов, любят закрыть глаза, а не про сальдо) имеет ещё и неочевидные, на "отступление" от процесса. В отличии от интуитивного принятия...
-30 подписок на неактивные 3+ месяца аккаунты, не генерирующие интересный контент и просто людей "ля, а это вообще кто". В основном предыдущие волны миграций из твиттура. Иронично, что в подписках были пара игнорируемых.
Официальный iOS app for Mastodon утомил просирать мои посты. Не первый раз. В заголовке пишет "Публикуем пост....", но это может длиться вечно и нихрена он не опубликует в итоге. И достать этот пост из списка публикуемых — никак. Берёт и в наглую просирает 500 символов пользовательского ввода. Худшее что может делать приложение, предназначенное для пользовательского ввода.
core i3 8100, 1 x 8gb DDR4 2400, WD Blue sata 256gb
на
core i7 9700k, 4 x 8gb DDR4 2666, 2tb nvme в PCI-E 3.0?
Ещё, наверное, надо старенький netgear с 802.11n ей поменять на mikrotik hap ac2, когда перееду и витуху сподобиться перетянуть на нормальные 4 жилы. Ух заживёт.
В отеле пиздец как холодно (20.7°С), кондей чот не могёт в обогрев. Простывать в отпуске как-то не вариант.
Техник потыкался во второй раз под потолком, кондей дошёл до 21.7 и усё. За окном орут дети. Полночь. Второе одеяло как костыль несут уже 15 минут. Ходил погреться на балкон.