Forwarded from Максим Цепков (Maxim Tsepkov)
Теперь мои комментарии, тоже в виде тезисов.
* У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня - значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе - чтобы отличаться от глубоких барельефов Возрожедния, которые уже у всех были. Здесь логика - та же.
* Как мне рассказали после лекции, первый черный квадрат был вполне утилитарной вещью - это часть декорации к спектаклю, где такая картина, наверное, была уместна по замыслу. А дальше - идея зацепила.
* Очень забавно: Чехов критикует мещан за отсутствие смысла, а Малевич - за то, что они везде ищут смысл. Хотя тут можно понять: у тех, кого называли мещанами, понятный смысл жизни из простых человеческих радостей. Они не ищут высокого предназначения, и не признают непонятное, художнику с ними сложно. Это целенаправлено разрушали, и в 1920-е, пока основным мотивом в СССР было низвержение старого супрематизм был в почете. А потом пошли эпоха, когда потребовалось конструирование нового.
* По сути, супрематизм - начало движение деконструкции смыслов. Тогда оно было в форме протестов против предписываемой традицией формы, которая застыла настолько, что тоже была лишена смысла. Но позднее, во второй половине 20 века у деконструкции появилось идеологическое обоснование, и объявлена долгом. И деконструкция искусства - часть этого мейнстрима. В этой концепции ценность искусства определяется замыслом автора и мерой его страдания, оцениваемой по его собственным заявлениям. За подробностями могут оправить в мой пост https://mtsepkov.org/Snowflake и пост https://ivanov-petrov.livejournal.com/2287616.html Это - гораздо более поздняя история, и отдельный вопрос - в каком объеме это было у Малевича, а насколько это - поздние интерпретации. Потому как сейчас любят говорить, что Достоевский воспевал страдающих, а он их не воспевал, он лишь показывал, что бедные - тоже люди, они живут и страдают также как остальные, сообщение было другим.
На этом все. В комментариях можно обсуждать подробнее. Или очно на конференциях.
А, еще в ответах на вопросы было про нейросеть, которая может создать любую абстракцию. Позиция Александра: нейросеть не может быть автором произведения, только производителем. А автор - тот кто впишет это в историю искусства. В общем, это логично, если в произведении главное - идея, то автор - тот кто написал промпт, а потом смог объяснить, а нейросеть - инструмент.
* У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня - значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе - чтобы отличаться от глубоких барельефов Возрожедния, которые уже у всех были. Здесь логика - та же.
* Как мне рассказали после лекции, первый черный квадрат был вполне утилитарной вещью - это часть декорации к спектаклю, где такая картина, наверное, была уместна по замыслу. А дальше - идея зацепила.
* Очень забавно: Чехов критикует мещан за отсутствие смысла, а Малевич - за то, что они везде ищут смысл. Хотя тут можно понять: у тех, кого называли мещанами, понятный смысл жизни из простых человеческих радостей. Они не ищут высокого предназначения, и не признают непонятное, художнику с ними сложно. Это целенаправлено разрушали, и в 1920-е, пока основным мотивом в СССР было низвержение старого супрематизм был в почете. А потом пошли эпоха, когда потребовалось конструирование нового.
* По сути, супрематизм - начало движение деконструкции смыслов. Тогда оно было в форме протестов против предписываемой традицией формы, которая застыла настолько, что тоже была лишена смысла. Но позднее, во второй половине 20 века у деконструкции появилось идеологическое обоснование, и объявлена долгом. И деконструкция искусства - часть этого мейнстрима. В этой концепции ценность искусства определяется замыслом автора и мерой его страдания, оцениваемой по его собственным заявлениям. За подробностями могут оправить в мой пост https://mtsepkov.org/Snowflake и пост https://ivanov-petrov.livejournal.com/2287616.html Это - гораздо более поздняя история, и отдельный вопрос - в каком объеме это было у Малевича, а насколько это - поздние интерпретации. Потому как сейчас любят говорить, что Достоевский воспевал страдающих, а он их не воспевал, он лишь показывал, что бедные - тоже люди, они живут и страдают также как остальные, сообщение было другим.
На этом все. В комментариях можно обсуждать подробнее. Или очно на конференциях.
А, еще в ответах на вопросы было про нейросеть, которая может создать любую абстракцию. Позиция Александра: нейросеть не может быть автором произведения, только производителем. А автор - тот кто впишет это в историю искусства. В общем, это логично, если в произведении главное - идея, то автор - тот кто написал промпт, а потом смог объяснить, а нейросеть - инструмент.
Livejournal
Wokeism: идеология
Достойный юзер redstarcreative написал несколько комментариев, где кратко охарактеризовал историю и нынешнее состояние господствующей в свободном мире идеологии. Тема для многих крайне актуальная, а такого краткого и ясного изложения еще поискать. Этот юзер…
🖐 Не пропустите доклады, которые начинаются в 17:10
⠀
🏰 «00 Зал - Башня». Архитектура биллинга: как не стать единой точкой отказа. Илья Иванов (Яндекс 360)
Интересный архитектурный кейс от Яндекса по созданию высоконагруженного биллинга.
⠀
🔘 Зал «08 Шатер Голубой». Быстро — не всегда хорошо: рейтлимиты в мультикластерном окружении. Дмитрий Виноградов (Wildberries)
Для контроля входящего RPS в сервисах применяют rate limit. Вот только он реализуется или как простой in-memory-счетчик, или более продвинуто — как счетчик во внешнем K/V. В докладе Дмитрий пошел в своей работе дальше — к более сложным решениям.
⠀
🔹 «03 Зал Синий». Продолжение мастер-класса «Разделим данные». Алексей Лосев (Яндекс Маркет)
Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Как научить MongoDB делать горячие физические бэкапы. Юрий Фролов (Yandex Cloud)
История о том, как Яндекс возвращал возможность физических бэкапов в MongoDB. Будет много подробностей про движок базы, про подход MongoDB к хранению данных и про то, как написать собственную логику бэкапа.
⠀
🟢 «06 Зал Зеленый». Как мы сделали собственный Software-Defined Storage для публичного облака Cloud.ru. Сергей Лысанов (Cloud.ru)
Глубоко технический доклад про реализацию собственного хранилища в условиях больших нагрузок и критических систем вокруг. Если вам нравится разбираться во внутрянке таких систем и специфике хранения данных — этот доклад для вас.
⠀
🔵 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)
В результате воркшопа каждый участник поймет, как строить системы RAG (Retrieval Augmented Generation), узнает их особенности и получит собственную работоспособную систему.
⠀
🏰 «00 Зал - Башня». Архитектура биллинга: как не стать единой точкой отказа. Илья Иванов (Яндекс 360)
Интересный архитектурный кейс от Яндекса по созданию высоконагруженного биллинга.
⠀
🔘 Зал «08 Шатер Голубой». Быстро — не всегда хорошо: рейтлимиты в мультикластерном окружении. Дмитрий Виноградов (Wildberries)
Для контроля входящего RPS в сервисах применяют rate limit. Вот только он реализуется или как простой in-memory-счетчик, или более продвинуто — как счетчик во внешнем K/V. В докладе Дмитрий пошел в своей работе дальше — к более сложным решениям.
⠀
🔹 «03 Зал Синий». Продолжение мастер-класса «Разделим данные». Алексей Лосев (Яндекс Маркет)
Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Как научить MongoDB делать горячие физические бэкапы. Юрий Фролов (Yandex Cloud)
История о том, как Яндекс возвращал возможность физических бэкапов в MongoDB. Будет много подробностей про движок базы, про подход MongoDB к хранению данных и про то, как написать собственную логику бэкапа.
⠀
🟢 «06 Зал Зеленый». Как мы сделали собственный Software-Defined Storage для публичного облака Cloud.ru. Сергей Лысанов (Cloud.ru)
Глубоко технический доклад про реализацию собственного хранилища в условиях больших нагрузок и критических систем вокруг. Если вам нравится разбираться во внутрянке таких систем и специфике хранения данных — этот доклад для вас.
⠀
🔵 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)
В результате воркшопа каждый участник поймет, как строить системы RAG (Retrieval Augmented Generation), узнает их особенности и получит собственную работоспособную систему.
👍3
Forwarded from Максим Цепков (Maxim Tsepkov)
#Highload Филипп Дельгядо. Enterprise deploy: почему это больно. Рассказ о технике повышения безопасности деплоя. Особенно важно это для enterprise-решений, которые разворачиваются у клиента: мы не контролируем процесс обновлений и их использование.
Когда-то были монолиты, которые для обновлений останавливали. Сейчас у нас много экземпляров серверов, которые работают с общей базой данных, которая тоже может быть в нескольких экземплярах, и остановить работу для изменения невозможно. Изменения правильно делить не на совместимые и несовместимые, а по безопасности: почти безопасные, возможно опасные и точно опасные. Создать новую таблицу - безопасно. Добавить поле - практически безопасно, но требует краткой блокировки таблицы, и на смеси olap и oltp транзакций под высокой нагрузкой это может выстрелить: oltp задержат дольше допустимого. А создание индекса во многих базах блокирует таблицу надолго, а в PostgreSQL есть специальные методы, как это сделать безопасно, ими надо владеть. Добавление нового значения в enum - опасность больше, надо разбираться с работой старых сервисов с объектами, у которых новое значение. Может быть, что такие записи в них в принципе не попадут, но это всегда не точно.
Надо уметь писать безопасные скрипты обновления с миграцией данных. Если мы хотим поменять тип данных в поле, то безопасное решение - новое поле с новым типом, при этом заполнение его по старому - отдельный скрипт, работающий в фоне и не нагружающим базу. И в переходный период надо уметь работать с объектами, когда только старое поле заполнено. А опасные изменения - это когда мы меняем семантику, добавляем side-эффект. Все теоретически знают, что это делать не нужно, а практически достаточно часто делают. Идет эволюция, и вместо основного телефона клиента становится два: для нотификация с подтверждением и для экстренных обращений, и вопрос безопасности таких изменений - сложный.
Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:
* Версионирование по методам, а не целиком.
* Изменения окружаем флагами для котроля нового поведения
* Используем тольо безопасные изменения внутри endpoint
* Маршрутизация запросов - чтобы метод получал только понятное
* Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
* Нужен инструмент управление фича-флагами: рассылка по сервисам, контроль зависимостей, канареечные флаги вместо разнесения по узлам сети, удаление неактуальных флагов
Асинхронные взаимодействия через очереди. Тут нет мгновенного изменения, в очереди живут необработанные события старых версий. И на них нельзя запустить обновление, они придут в виде, в котором посланы. Мы не всегда знаем участников взаимодействия - что читает, кто пишет. И делать версии событий базовые инструменты не позволяют. И тут хороших решений нет.
* Самое простое - новый топик для новых событий. Но при этом мы теряем порядок и партиционирование, нужно сложное переключение и администрирование.
* Сначала обновляем консьюмеров, потом продьюсера. Тогда сервисы перестали быть автономны по деплою, и пояляются проблемы с откатом консьюмеров - для этого надо отвалить продьюсер. Частичное решение - фича-флаг в продьюсере, но то, что в очереди - лежит.
* Отправка нескольких версий - и консьюмер выбирает нужную. Это сложно в реализации, потому что стандартные способы передачи и контроля перестают работать - у вас несколько схем на одно событие, например.
* Можно возложить маршрутизацию на service mesh - чтобы он отправлял на нужных консьюмеров.
А еще - можно не делать асинхронное. Вам нужно сглаживать пики - уберите этот буфер внутрь сервиса, а не располагайте между.
Когда-то были монолиты, которые для обновлений останавливали. Сейчас у нас много экземпляров серверов, которые работают с общей базой данных, которая тоже может быть в нескольких экземплярах, и остановить работу для изменения невозможно. Изменения правильно делить не на совместимые и несовместимые, а по безопасности: почти безопасные, возможно опасные и точно опасные. Создать новую таблицу - безопасно. Добавить поле - практически безопасно, но требует краткой блокировки таблицы, и на смеси olap и oltp транзакций под высокой нагрузкой это может выстрелить: oltp задержат дольше допустимого. А создание индекса во многих базах блокирует таблицу надолго, а в PostgreSQL есть специальные методы, как это сделать безопасно, ими надо владеть. Добавление нового значения в enum - опасность больше, надо разбираться с работой старых сервисов с объектами, у которых новое значение. Может быть, что такие записи в них в принципе не попадут, но это всегда не точно.
Надо уметь писать безопасные скрипты обновления с миграцией данных. Если мы хотим поменять тип данных в поле, то безопасное решение - новое поле с новым типом, при этом заполнение его по старому - отдельный скрипт, работающий в фоне и не нагружающим базу. И в переходный период надо уметь работать с объектами, когда только старое поле заполнено. А опасные изменения - это когда мы меняем семантику, добавляем side-эффект. Все теоретически знают, что это делать не нужно, а практически достаточно часто делают. Идет эволюция, и вместо основного телефона клиента становится два: для нотификация с подтверждением и для экстренных обращений, и вопрос безопасности таких изменений - сложный.
Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:
* Версионирование по методам, а не целиком.
* Изменения окружаем флагами для котроля нового поведения
* Используем тольо безопасные изменения внутри endpoint
* Маршрутизация запросов - чтобы метод получал только понятное
* Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
* Нужен инструмент управление фича-флагами: рассылка по сервисам, контроль зависимостей, канареечные флаги вместо разнесения по узлам сети, удаление неактуальных флагов
Асинхронные взаимодействия через очереди. Тут нет мгновенного изменения, в очереди живут необработанные события старых версий. И на них нельзя запустить обновление, они придут в виде, в котором посланы. Мы не всегда знаем участников взаимодействия - что читает, кто пишет. И делать версии событий базовые инструменты не позволяют. И тут хороших решений нет.
* Самое простое - новый топик для новых событий. Но при этом мы теряем порядок и партиционирование, нужно сложное переключение и администрирование.
* Сначала обновляем консьюмеров, потом продьюсера. Тогда сервисы перестали быть автономны по деплою, и пояляются проблемы с откатом консьюмеров - для этого надо отвалить продьюсер. Частичное решение - фича-флаг в продьюсере, но то, что в очереди - лежит.
* Отправка нескольких версий - и консьюмер выбирает нужную. Это сложно в реализации, потому что стандартные способы передачи и контроля перестают работать - у вас несколько схем на одно событие, например.
* Можно возложить маршрутизацию на service mesh - чтобы он отправлял на нужных консьюмеров.
А еще - можно не делать асинхронное. Вам нужно сглаживать пики - уберите этот буфер внутрь сервиса, а не располагайте между.
🖐 Друзья, в 18:20 мы ждём вас на заключительных докладах Saint HighLoad++ 2024:
⠀
🏰 «00 Зал - Башня». Как мы шли к 5000 RPS на запись. Ян Силов (Ozon)
Хорошая история повышения нагрузки на запись и борьбы с ней. Вместе с докладчиком погрузимся в анализ проблем и оптимизацию.
⠀
🔘 Зал «08 Шатер Голубой». Как воспитать себе помощника: применение локального ИИ для разработки. Алексей Цветков (Независимый эксперт)
Трудно делать содержательный доклад на горячую тему: ожидания высоки, готовность аудитории низкая. И Алексей справился блестяще! Это интересный и полезный доклад, рекомендован всем, кого интересует практическое применение AI в повседневной работе.
⠀
🟣 «04 Зал Красный». Как мы монгу физически бэкапили. Владимир Гошев (Yandex Cloud)
Рассказ о том, как Яндекс учился бэкапить кластеры MongoDB для своих клиентов: чтобы бэкапы занимали адекватное количество места, с ними было легко работать, а главное — чтобы из них можно было восстановить консистентный кластер!
⠀
🏰 «00 Зал - Башня». Как мы шли к 5000 RPS на запись. Ян Силов (Ozon)
Хорошая история повышения нагрузки на запись и борьбы с ней. Вместе с докладчиком погрузимся в анализ проблем и оптимизацию.
⠀
🔘 Зал «08 Шатер Голубой». Как воспитать себе помощника: применение локального ИИ для разработки. Алексей Цветков (Независимый эксперт)
Трудно делать содержательный доклад на горячую тему: ожидания высоки, готовность аудитории низкая. И Алексей справился блестяще! Это интересный и полезный доклад, рекомендован всем, кого интересует практическое применение AI в повседневной работе.
⠀
🟣 «04 Зал Красный». Как мы монгу физически бэкапили. Владимир Гошев (Yandex Cloud)
Рассказ о том, как Яндекс учился бэкапить кластеры MongoDB для своих клиентов: чтобы бэкапы занимали адекватное количество места, с ними было легко работать, а главное — чтобы из них можно было восстановить консистентный кластер!
❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Первая в России PostgreSQL Pre-Commitfest Party: итоги!
✔️100+ слушателей на публичном ревью патчей в PostgreSQL 18
✔️900+ гостей в шатре Postgres Professional!
✔️4 демонстрации BiHA и Shardman
✔️600+ участников квиза
✔️15 коробок разыгранного мерча
Спасибо всем, кто провел с нами эти два дня и до встречи на следующей вечеринке российского постгрес-сообщества!
Вместе мы – Postgres!
✔️100+ слушателей на публичном ревью патчей в PostgreSQL 18
✔️900+ гостей в шатре Postgres Professional!
✔️4 демонстрации BiHA и Shardman
✔️600+ участников квиза
✔️15 коробок разыгранного мерча
Спасибо всем, кто провел с нами эти два дня и до встречи на следующей вечеринке российского постгрес-сообщества!
Вместе мы – Postgres!
❤4👍3🔥2❤🔥1
Media is too big
VIEW IN TELEGRAM
💥 Друзья, Saint HighLoad++ 2024 завершилась!
⠀
Мы благодарим каждого из вас за участие: кто был на площадке, в онлайн, спикеров и партнёров! Эти два дня были очень насыщенные и мы надеемся, что для вас они прошли плодотворно и интересно. Будем рады вашей обратной связи 💚
⠀
До встречи на HighLoad++ 2024 🙌
⠀
Мы благодарим каждого из вас за участие: кто был на площадке, в онлайн, спикеров и партнёров! Эти два дня были очень насыщенные и мы надеемся, что для вас они прошли плодотворно и интересно. Будем рады вашей обратной связи 💚
⠀
До встречи на HighLoad++ 2024 🙌
❤35🔥11🎉2
Как бороться с типовыми причинами отказа? Для начала их нужно обнаружить.
Рассмотрим элементы инженерной практики, которые обеспечивают высокую доступность системы и оперативное расследование инцидентов. Коснёмся памяти, разберём базу данных, поговорим про ТСР-соединения. Посмотрим, как разрабатывают, эксплуатируют и отлаживают высоконагруженные системы в Газпромбанке.
Константин Козловский из Газпромбанк.Тех расскажет про проблемы backend разработки на Java и Kotlin.
Подробности в статье: https://habr.com/ru/companies/oleg-bunin/articles/823498/
Рассмотрим элементы инженерной практики, которые обеспечивают высокую доступность системы и оперативное расследование инцидентов. Коснёмся памяти, разберём базу данных, поговорим про ТСР-соединения. Посмотрим, как разрабатывают, эксплуатируют и отлаживают высоконагруженные системы в Газпромбанке.
Константин Козловский из Газпромбанк.Тех расскажет про проблемы backend разработки на Java и Kotlin.
Подробности в статье: https://habr.com/ru/companies/oleg-bunin/articles/823498/
Хабр
Точки отказа в HighLoad-системах
Как бороться с типовыми причинами отказа? А самое главное — как их обнаружить? Рассмотрим лучшие элементы инженерной практики, обеспечивающие высокую доступность системы и оперативное расследование...
💯1