Олег, 31 годик, решил почитать что такое федеративное государство в википедии, чтобы ликвидировать безграмотность и лучше сраться в дискуссиях о федиверсе.
Решительно не понимаю нихера. Если рассматривать федерацию (абстрактную) как добровольное объединение с взаимной выгодой - почему сецессия / федиблок (ну или что там есть ещё пожёсче чем забанить пачку инстансов, вроде ничего) / сепаратизм - это что-то немыслимо плохое. Ну типа пусть выходят, попробуют чо как там, захотят - вернутся, двери открыты.
Но раз это что-то немыслимо плохое и подлежит радикальному упреждению, это ж не федеративное, а унитарное объединение, выходит?
Или этот термин - попытка усидеть на двух стульях, типа мы тут все друзяшки, друзяшки сука, вякнешь мимо - введём войска/будем анонсить как токсичный инстанс и рекомендуемый к бану?
В очередной раз думаю о том, что fediverse должен иметь несколько уровней иерархии, в которые инстансы могли бы объединяться во что-то похожее на государство, со своей общей внутренней политикой, с возможными особенностями поверх неё (региональным законодательством) в пределах инстанса, которое уже само граничит с другими государствами и выстраивает "международную политику".
Ага, дочитал до конфедерации и всё мне ясно стало теперь. Чюваки, нам нужен #confediverse.
С точки зрения законодательства, конечно любопытная штука получается. Если законы субъекта федерации сильно переопределяют базовые - это ж каково по ним путешествовать/инстахоппить? Унификация прям просится хотя бы ради устранения бардака.
Дочитал до конституционных/договорных/мягких федераций и фиксации принципа территориальной целостности и все мои вопросы отпали.
Олег, 31 годик, решил почитать что такое федеративное государство в википедии, чтобы ликвидировать безграмотность и лучше сраться в дискуссиях о федиверсе.
Решительно не понимаю нихера. Если рассматривать федерацию (абстрактную) как добровольное объединение с взаимной выгодой - почему сецессия / федиблок (ну или что там есть ещё пожёсче чем забанить пачку инстансов, вроде ничего) / сепаратизм - это что-то немыслимо плохое. Ну типа пусть выходят, попробуют чо как там, захотят - вернутся, двери открыты.
Решил прибраться в своём блоге. Нашёл бриллиант - идею игры про "политику компании".
Игроку предлагается сформулировать политику компании, которая будет использоваться при принятии решений. Каким должен быть интерфейс для этого? Ну, например вопросник из 10-100 вопросов. После формулировки политики компании не остаётся больше никакого интерактива - все решения принимаются автоматически на основе данной политики, а с компанией начинают происходить СОБЫТИЯ.
Хардмод - сформулировать политику в свободной форме, без списка вопросов, все неопределённые вопросы будут решаться случайным образом.
Альтернативные варианты с той же механикой: управление государством, эксперименты с законодательной властью.
Целевая аудитория - молодые айтишники, мечтающие “заменить этих эффективных менеджеров одним скриптом”.
Решил прибраться в своём блоге. Нашёл бриллиант - идею игры про "политику компании".
Игроку предлагается сформулировать политику компании, которая будет использоваться при принятии решений. Каким должен быть интерфейс для этого? Ну, например вопросник из 10-100 вопросов. После формулировки политики компании не остаётся больше никакого интерактива - все решения принимаются автоматически на основе данной политики, а с компанией начинают происходить СОБЫТИЯ.
Лучше бы баб ебал, конечно. Одна строчка, написанная по приколу, за вечер превратилась в репу на 225 строк кода с тестами и утилитами и завёрнута в пакет в pypi.
Недавно, пока стригся, как-то разговор не клеился с парикмахером (и слава богу) и я провалился в ностальгию.
Вспоминал чудное время игры в #WoW (#WotLK) на пиратском сервере, тот азарт рейдов, ротациях, одевании твинков, чудесные схемы ролла, начисление очков, за которые можно было забирать шмотки в гильдии и т.д.
Вспомнил, почему я забросил все MMORPG - я не владею своим персонажем. То есть прикрывает оунер свой сервер и весь мой прогресс коту под хвост. Казалось бы проблема может решаться федеративной архитектурой и интерконнектом между серверами. Но так невозможно доверять прогрессу других игроков - накрутит себе кто-нибудь .additem'ов и .addskill'ов вообще от других классов (мне особенно нравился ДК с пассивками frost-мага, shadow-priest, destro-варлока, воина, энха и роги, благодаря которым все нагибались буквально одной левой (урон левой рукой был выше урона правой раза в два, благодаря стакающимся талантам).
И даже хз что с этим делать. Строить федерацию на доверии между администраторами, разве что, но как сделать миграцию между серверами, takeout данных - хз.
Вспомнил и прелестное читерство, которым я развлекался в обход античита. Заходим в игру в два окна с разных аккаунтов. Кидаем своему же персонажу приглашение в группу, создаём рейд, ставим сложность 25 героик. Заходим обоими в ЦЛК. Дальше сложная пляска с бубном. Была такая прога - XYZ, которая позволяла "летать". Но античит её палил. Но если по чуть-чуть - не палил. Собственно - написал программу на autoit, которая позволяла двигаться в нужном направлении маааааааленькими шажочками. И сервер этого не видел. И этого было достаточно для того, чтобы сквозь текстуры прямо от входа в цитадель подняться к Саурфангу Смертоносному. НПС стоял на месте, бой можно было запустить. Итак - оба персонажа на месте. Нужен был один танк, один РДД, хорошо умеющий восстанавливать ману и имеющий много доток, которые стабильно наносили бы урон где-то раз в секунду. Дальше происходило следующее - танк уводится в текстуры за Саурфангом. Где-то в середину шпиля. РДД возвышается в воздухе метрах в 10 над землёй так, чтобы Саурфанг не задевал. Во время боя нужно постоянно накидывать доты, т.к. спустя несколько секунд без урона Саурфанг понимал бы, что боя-то нет и вышел бы из него, восстановив здоровье. А танк нужен, чтобы в короткие секунды между уроном Саурфанг на него агрился. Но при получении урона разворачивался и снова шёл к РДД. Варлоком фармить его было просто идеально - простая ротация, проклятия, порча, поджигание, манатап и высасывание жизни не давали Саурфангу отдохнуть. Таким образом он убивался в соло. С хорошей долей вероятности с него падала Воля Смертоносного - одна из лучших серёжек для МДД, за которую вечно были срачи. И с 100% долей вероятности с него падали "печеньки", которые можно было обменивать на сетовые шмотки, что тоже топчик.
В итоге твинка можно было одеть так, что его брали бы в рейды буквально за 2 недели. А помимо ЦЛК 25 гер ещё были 10 об, 10 гер, 25 об. В общем, прибарахлиться удавалось неплохо. А вот Халиона (да боже мой, вообще больше никого) таким образом завалить не удалось.
А сейчас... что сейчас, фармлю голду на показе баннеров в банке и прожимаю квест с ремонтом трёшки. Скучно-с.
Недавно, пока стригся, как-то разговор не клеился с парикмахером (и слава богу) и я провалился в ностальгию.
Вспоминал чудное время игры в #WoW (#WotLK) на пиратском сервере, тот азарт рейдов, ротациях, одевании твинков, чудесные схемы ролла, начисление очков, за которые можно было забирать шмотки в гильдии и т.д.
За полгода я прочитал треть книжки. За выходные на природе прочитал 30 страниц. Медленно.
Контрольная точка - это две метки в #wal с началом и концом. В начале фиксируется список грязных буферов, в конце - все зафиксированные на момент начала грязные буферы сдамплены на диск. По контрольной точке восстановливается согласованное состояние на момент её начала при восстановлении из резервных копий. Файлы wal, кроме предыдущей завершённой и текущей контрольной точки бесполезны. При достижении `max_wal_size` форсируется _внеплановая_ контрольная точка. Много внеплановых контрольных точек – плохо. С ними вообще любопытно: делаешь часто - лишние накладные расходы, плохо, делаешь редко – плохо, возрастает время восстановления, растёт объём хранимых wal-файлов. Это как менеджер, спрашивающий как дела по задаче. Подстраивать интервалы для checkpointer'а нужно по обратной связи из мониторинга, учитывая профиль нагрузки на систему. Такое себе, я ожидал больше динамики и автоматизации.
Мне понравился подход в сбросе грязных буферов на диск - трэкать скользящим окном время и объём IO на обработку предыдущих контрольных точек, если успеваем, то _замедляемся_, чтобы не создавать пиковую нагрузку в бутылочном горлышке системы (дисковой записи) на ровном месте. Это резервирует дополнительные ресурсы для штатного функционирования системы, которые могут _внезапно_ понадобиться.
Синхронный режим это медленная жопа, а много OLTP транзакций её насилуют. Поэтому для синхронного режима придумали батчинг записи коммитов в журнал, по дефолту он выключен, регулируется опцией commit_delay. Нравится метафора из книги с удерживаемой кнопкой дверью лифта, когда первая транзакция, которая готова закоммититься, ждёт немного, вдруг с ней за компанию ещё одна транзакция влетит записываться на диск.
Асинхронный режим допустим, если вы готовы потерять пару сотен последних транзакций, даже если нужно будет повторить их в ручном режиме или компенсировать убытки из своего кармана. Исправный ИБП, сигнал о потере питания от которого вызывает штатное завершение работы системы, снижает вероятность такой ситуации раз в десять.
У журнала несколько уровней записи - minimal, replica, logical. Как я понял, logical это для master, replica это для slave, minimal это для fucking slaves. Про logical надо бы подробнее почитать, в книжке он мимоходом упоминается. Синхронная репликация журнала, когда коммит записи на мастере означает гарантию чтения этой записи на реплике, звучит как головная боль для администратора БД и тормоза. Мастер-мастер репликация звучит ещё более сложной. Асинхронная репликация журнала _без_ гарантии чтения с реплики выглядит гораздо проще, кажется большинству систем этого за глаза хватать должно.
- 1 master,
- 1-2 slaves, выделенных для снятия резервных копий,
- N-slaves для readonly OLAP-нагрузки.
Интересно, кстати, как с использованием этого у #mastodon обстоят дела, уж чего-чего, а readonly нагрузки тут достаточно.
Возникшие вопросы, которые пока остаются без ответа
- Как в PostgreSQL выглядит инициализация дополнительной реплики и какую нагрузку это создаёт на master?
- Возможна ли иерархическая репликация для распределения сетевой нагрузки на Master?
- Как себя в таком случае чувствуют промежуточные полумастер-реплики?
За полгода я прочитал треть книжки. За выходные на природе прочитал 30 страниц. Медленно.
Контрольная точка - это две метки в #wal с началом и концом. В начале фиксируется список грязных буферов, в конце - все зафиксированные на момент начала грязные буферы сдамплены на диск. По контрольной точке восстановливается согласованное состояние на момент её начала при восстановлении из резервных копий. Файлы wal, кроме предыдущей...
Нашёл я тут значит свои наработки 8-летней давности на #bash и немножко причесал.
Короче - схема резервного копирования с чем-то типа кольцевого буфера в файловой системе, сделанная поверх хардлинков.
Заточена под то, чтобы хранилось не больше 42 + лет эксплуатации резервных копий при ежедневном копировании и не больше 66 + лет эксплуатации - при ежечасном.
Найти #бэкап легко. Один и тот же бэкап может одновременно лежать в ежегодных, ежемесячных, ежедневных и ежечасных копиях, но, благодаря хардлинкам, это будет один файл. И создаваться он будет всего один раз. В итоге экономится дисковое I/O.
А самая прелесть - офигенно простая очистка лишнего. Просто ищем файлы с одной единственной ссылкой.
Нашёл я тут значит свои наработки 8-летней давности на #bash и немножко причесал.
Короче - схема резервного копирования с чем-то типа кольцевого буфера в файловой системе, сделанная поверх хардлинков.
Заточена под то, чтобы хранилось не больше 42 + лет эксплуатации резервных копий при ежедневном копировании и не больше 66 + лет эксплуатации - при ежечасном.
Глянул кусочек highload.guide, выцепил хорошую выжимку про классификацию репликаций:
- логическая - работает с кортежами; пример - row based binary log в MySQL; бутылочное горлышко - процессор slave.
- физическая - работает со страницами; примеры - pg_wal, innodb undo-redo; бутылочное горлышко - диск (не совсем понял master'а или slave'а, не совсем понял, а как же буферы; возможно дело в большей степени касается MySQL с несколькими журналами одновременно)
- statement based - сплошная боль, есть места где можно получить неконсистентные данные между master и slave, но в случае условной бигдаты - очень низкие накладные расходы на передачу данных по сети, большой update на всю таблицу прилетит практически одним запросом; разве что выполнять его придётся заново на slave, из-за этого может быть длинный лаг репликации.
Если slave может блокировать удаление журнала master'ом, чтобы догнаться в случае ребута, чем больше отставание, тем больше размер журнала. Если slave вообще не догоняет master в принципе и отставание только нарастает - со временем это закончится забитым дисковым хранилищем.
В PostgreSQL есть Logical Log Streaming Replication, который позволяет не миррорить часть таблиц на slave. Как это применять - я не придумал. В теории можно не хранить на слейвах для актуальных данных архивные данные, что позволит немного сэкономить на дисковом пространстве, особенно если slave'ов много.
P.S:
- Раньше жил в прекрасном мире, где БД находится на том же сервере, где и приложение, ни о какой репликации и не думал.
- Сейчас живу в прекрасном мире, где БД поддерживает отдельная команда, репликация уже готова, хоть и без гарантии синхронных записи на мастер и чтения со слэйва (а я и не против), бери да пользуйся.
Глянул кусочек highload.guide, выцепил хорошую выжимку про классификацию репликаций:
- логическая - работает с кортежами; пример - row based binary log в MySQL; бутылочное горлышко - процессор slave.
- физическая - работает со страницами; примеры - pg_wal, innodb undo-redo; бутылочное горлышко - диск (не совсем понял master'а или slave'а, не совсем понял, а как же буферы; возможно дело в большей степени касается MySQL с несколькими...
У меня есть три "потерянные" вещи, которые я долго откладываю восстановить и отсутствие которых очень больно бьёт по качеству жизни.
1. Личный пользовательский десктопный компьютер, на который легко переключаться с рабочего ноутбука, которые находятся на одном и том же рабочем столе. Из-за этого часть личных дел "протекла" на рабочий ноутбук. Вряд ли на нём есть много чего для слежки за сотрудниками, тут базовые рабочие процессы-то на линуксах не особо поддерживают, на входе я пару часов ёбся с интранет SSL-сертификатами и сменой пароля к SSL-сертификату для VPN (в итоге сделал это внутри контейнера с предыдущей Ubuntu LTS). У всех маки. Возможно переключаться будет впадлу и здесь меня может спасти nextcloud. А может и не спасти.
Вообще переключение у меня устроено так - есть usb-свитч, есть два HDMI-провода, воткнутые в большой монитор. Для переключения надо нажать кнопочку на USB-свитче, а потом кнопочку на мониторе для переключения источника. Такое себе удобства. Так-то второй монитор есть, но я его чот не использую, хотя казалось бы - разберись уже с usb type-c -> displayport и будет тебе счастье. Глядишь, ещё и заряжаться от монитора можно будет. Или монитор питать. Но эт не точно. А пока блок питания ноута (гигантский, сука, весит больше чем макбук про 15' наверное) прикрутил стяжками к столу и мне норм.
2. Планировщик для того чтобы внятно и раздельно планировать краткосрочную рутину, среднесрочные дела и встречи и долгосрочные проекты. Постоянно всё проёбываю, календарь игнорирую по той причине что он гвоздями прибит к _датам_ вместо _последовательностей_.
У меня в целом есть где-то на 60% дописанный планировщик поддерживающий нужный мне подход, я бы кое-где поэкспериментировал ещё с подходом, но чтобы двигаться нормально нужно менять архитектуру, очень многое зависит от удобства интерфейса, а на формах, которые рендерятся на бэкенде далеко не уедешь. Наверное за день реально распилить проект на бэк, состоящий из API и фронт на реакте (заодно, глядишь, на работе смогу фронтам ТЗ мерж-реквестами ставить, пока я в режиме read-only там, потому что даже не ебу как это всё протестировать).
3. Дневник, чтобы спускать пар, поэтому у меня стала всё чаще взрываться жопа. Куда-то просрал свой контейнер с мастодоном, надо ещё раз порыться по /var/lib/lxc на трёх железках.
Попробую за майские праздники восстановиться, сегодняшний день я посвящаю комплютору.
У меня есть три "потерянные" вещи, которые я долго откладываю восстановить и отсутствие которых очень больно бьёт по качеству жизни.
1. Личный пользовательский десктопный компьютер, на который легко переключаться с рабочего ноутбука, которые находятся на одном и том же рабочем столе. Из-за этого часть личных дел "протекла" на рабочий ноутбук. Вряд ли на нём есть много чего для слежки за сотрудниками, тут базовые рабочие процессы-то на линуксах не особо поддерживают, на входе я пару часов ёбся с интранет...
Сходил вчера к нутрициологу. Теперь у меня в жизни появилась женщина, которая спрашивает как я покушал и как я покакал. Аж на слезу пробило, лол.
По её словам, в принципе если процентов на 5 скорректировать мои пищевые привычки и чуток дожать дисциплину, усвоение пищи и витаминов подрастут процентов на 15, можно будет меньше хавать, а я слегка схудну и её приёмы отобьются по баблу за счёт экономии на продуктах за 2-3 месяца :D
Самое сложное это, конечно, правильно жрать колёса. Те, которые я ем за полчаса до еды ещё ладно. Но тут она чот парочку ещё накинула, хотя у меня свои уже в таблетницу не влезают. Сейчас я иногда такой "бляяя колёса" и просто закидываю всю дневную пачку в себя. Плохо, но всяко лучше, чем не закинуть. А тут "это за полчаса до еды утром, после нельзя; это между приёмами пищи, но перекусы можно игнорировать, это через полчаса после еды, а это прямо с едой, но только если она достаточно жирная".
Ещё сейчас смотрю на результаты анализов и прям вижу, как дисциплина, в теории, позволяет сократить дозировку колёс. И это тоже, сука, экономит бабки! Вот думаю, стоит ли с этой идеей к эндокринологу идти (по ДМС, конечно, а то его приём 2к стоит почти уже, без ДМС я бы даже не сомневался) или развлекаться самолечением.
Смущает то, что мы проворачиваем три эксперимента одновременно - снижаем кислотность желудка, докидываем лёгкое желчегонное и меняем 10% сливки в кофе на 3.2% молоко. Из-за этого не можем точно определить, что было эффективно, а что нет.
Сходил вчера к нутрициологу. Теперь у меня в жизни появилась женщина, которая спрашивает как я покушал и как я покакал. Аж на слезу пробило, лол.
По её словам, в принципе если процентов на 5 скорректировать мои пищевые привычки и чуток дожать дисциплину, усвоение пищи и витаминов подрастут процентов на 15, можно будет меньше хавать, а я слегка схудну и её приёмы отобьются по баблу за счёт экономии на продуктах за 2-3 месяца :D
Подумал тут, а ведь корелляции в трафике можно выявлять через эдакое подобие производных функций, не держа вообще всё в памяти. Берём 1000 пакетов. Накладываем 128 байт payload ethernet фрейма первого пакета на 128 таких же байт второго, совпадающая битмаска будет хэш-ключиком счётчика. Читаем третий, забываем первый, сравниваем со вторым. Повторяем. Берём топ счётчика и если он больше 50% то что-то тут не так. Так #ддосы можно в 99% случаев вообще вслепую выявлять, вообще не парся пакеты.
При хайлоадах можно просто 5-10-50-500 пакетов/сек хватать и как-нибудь скользящее окно замутить, чтобы всегда актуальная инфа была. Или 2 счётчика иметь, заполнять сперва один, потом второй, сравнивать между собой, потом первый занулять, заполнять заново. Ух бля, статистикал лёрнинг, нахуй.
Подумал тут, а ведь корелляции в трафике можно выявлять через эдакое подобие производных функций, не держа вообще всё в памяти. Берём 1000 пакетов. Накладываем 128 байт payload ethernet фрейма первого пакета на 128 таких же байт второго, совпадающая битмаска будет хэш-ключиком счётчика. Читаем третий, забываем первый, сравниваем со вторым. Повторяем. Берём топ счётчика и если он больше 50% то что-то тут не так. Так #ддосы можно в 99% случаев вообще вслепую выявлять, вообще не парся пакеты.
Записался на сдачу грейдов, но ощущаю это гиблым делом.
Вообще концепция довольно упоротая, поскольку текущая схема подразумевает взращивание эдакого универсального солдата, в то время как команда и проекты нуждаются в компетнциях дай боже процентам по 25, но, пожалуй, бутылочное горлышко - даже не идеи что сделать, чтобы стало хорошо, а банально время на то чтобы это сделать. И возникает конфликт - ради карьерного роста нужно задрачивать неважное в текущей практике, а это... внимание, энергия и время, которые мог бы потратить на развитие проекта.
Вот раньше просто было - вот тебе проект, вот тебе процент с ежемесячной подписки по хитрожопой функции, предполагающей рост проекта, ебашьте, сеньор джун. И сразу всё становится проще с приоретизацией, не ебёшь мозги себе вообще решительно ничем кроме максимизации прибыли и минимизации затрат.
Записался на сдачу грейдов, но ощущаю это гиблым делом.
Вообще концепция довольно упоротая, поскольку текущая схема подразумевает взращивание эдакого универсального солдата, в то время как команда и проекты нуждаются в компетнциях дай боже процентам по 25, но, пожалуй, бутылочное горлышко - даже не идеи что сделать, чтобы стало хорошо, а банально время на то чтобы это сделать. И возникает конфликт - ради карьерного роста нужно задрачивать неважное в текущей практике, а это... внимание, энергия и...
@strizhechenko удачи. вот тоже думаю что надо бы доучится до состояния что не совсем нуб и менять специальность. утомило. ну или поискать что то по текущей специальности..
@strizhechenko Подпишуть под каждым словом. Совсем долбанулись с этой телегой. Сейчас меня обзовут ретроградом и старпёром 😀, но я всё равно останусь при своём: мессенджеры для сиюмитной информации. И кроме текста и передачи файлов там ничего не надо. И шифрования, разумеется. А всё, что длиннее 1000 символов и реально полезное - в вики, форумы, сайты.
@strizhechenko
Что характерно, проблема в еще большем масштабе существует с Discord.
Кто-то поехавший решил, что там норм держать техническую информацию и понеслась.
Даже у нормальных опенсорс проектов бывает немало инфы доступно только там.
Вспомнил, как я в 2012 мастерил "убийцу микротика" для провайдеров - дистрибутив Linux для небольших провайдеров, заточенный под работу 10гбит/сек, назвали его XGE, типа X Gigabit Ethernet. В неправильной раскладке получалось ЧПУ, за что меня коллеги прозвали оператором ЧПУ.
В целом колхоз-колхозом, но опыт интересный. Много ядерного программирования, не только ОБЫЧНЫЙ ЛИНУКС ВЗЯЛ И НАСТРОИЛ И ДЕНЕГ ХОЧЕТ, а прям побитый продакшном проект, вот прям из коробки хоба и взлетает многое. Единый конфиг опять же, копию развернуть - буквально _один_ файл скинуть на новую установку, IP-адреса поменять и погнали. Да и в целом после предыдущей версии нашего роутера без ipset - это был глоток свежего воздуха в вопросе масштабирования, раньше на дереве цепочек iptables что acl, что NAT, что шейперы работали и это была жопа где-то после 2000 абонентов.
Увы, проект не взлетел, потому что небольшие провайдеры зажимают любую копеечку, а большие хотят большой американский вендор аппаратного решения. В целом, если бы в проект вложили где-то в 6-7 раз больше денег (и наняли в 3-4 раза больше людей, а не одного человека на полставки, потому что появился ещё один более выгодный проект), может быть что-то из этого и получилось. Но вышло немного иначе.
Решение о том, чтобы его похоронить принимали слишком долго и откладывали на потом. Даже на то, чтобы внятно опубликовать наработки ресурсов не нашлось, это ж время, и по истории коммитов пробежаться, понять в каком виде вообще выкладывать - в виде отдельных патчей или целиком всё дерево ядра, брендинг опять же пришлось бы делать, да и просто публикации мало, надо было бы людям которые зачем-то в issues пришли отвечать, ну и статейки на хабр, опеннет и ЛОР прости-господи клепать. В итоге так и забили болт.
Такая вот грустная история импортозамещения.
Тут заметил упоминание ЧПУ.
Вспомнил, как я в 2012 мастерил "убийцу микротика" для провайдеров - дистрибутив Linux для небольших провайдеров, заточенный под работу 10гбит/сек, назвали его XGE, типа X Gigabit Ethernet. В неправильной раскладке получалось ЧПУ, за что меня коллеги прозвали оператором ЧПУ.
#ФедиЧитальня
Предлагаю кому-нибудь присоединиться ко мне в чтении либо про кишочки постгреса (в открытом доступе легально): https://postgrespro.ru/education/books/internals
либо про высоконагруженные приложения, но мутите её где-нибудь сами (дорогобогато).
Я читаю такие вещи медленно и редко, поэтому предлагаю ритм для синхронизации – главу или 10-15 страниц в неделю (что меньше), но компания для чтения звучит как неплохой мотиватор не забить и дожать и мб в процессе ускориться.
О процессе: предлагаю просто раз в неделю под этим постом делать ветку дерева посвящённую прочитанной главе. Мне будет приятно послушать и поделиться мыслями как бы прочитанное применить в рабочем или пет-проекте.
#ФедиЧитальня
Предлагаю кому-нибудь присоединиться ко мне в чтении либо про кишочки постгреса (в открытом доступе легально): https://postgrespro.ru/education/books/internals
либо про высоконагруженные приложения, но мутите её где-нибудь сами (дорогобогато).
Я читаю такие вещи медленно и редко, поэтому предлагаю ритм для синхронизации – главу или 10-15 страниц в неделю (что меньше), но компания для чтения звучит как неплохой мотиватор не забить и дожать и мб в процессе ускориться.
О процессе: предлагаю...
Gregory's Server
