Представь, у тебя есть класс, который считает зарплату сотрудника: его KPI, премии и т. п., и создает PDF-отчет. Тебе нужно создать класс для подсчета зарплаты и генерации отчета по менеджеру. Учти, что премия и KPI у них одинаковый процент от зарплаты. Отличие лишь в том, что менеджер получает больше.
В первом предложении в зарплату входят KPI и премии, двоеточие в языке это подразумевает. В третьем предложении премия и KPI уже процент от зарплаты. Видимо, подразумевается от базы зарплаты. Менеджер - это типа не сотрудник? Класс, который нужно создать, уже есть, он полностью соответствует требованиям. Что выделяет менеджера, и зачем это учитывать отдельно - хз, не указано.
Автор с одной стороны очень расхлябан в формулировках, а с другой - требует душнильных вещей типа SOLID и проч.
Научность идеи связана с её статистически значимой полезностью, но под этикеткой «научности» популяризируется слишком уж много бесполезных идей. А со временем они превращаются в антинаучные догмы, тормозящие прогресс.
Во-первых, это утверждение внутренне противоречиво. Во-вторых, из того, что относится в вашей статье к науке, вы не назвали ни одной бесполезной идеи (я искренне надеюсь, что вы не считаете таковыми квантовую физику и ОТО). Так что очень странное заключение. Программирование я не считаю наукой, это инженерная практика. Нет никаких научно обоснованных эффективных техник программирования.
мы (как и некоторые другие современные движки) идем через концепцию локального Write Set.
Да, чувствуется, что вы ориентируетесь на какие-то движки. Расскажите поподробнее, чем вы вдохновляетесь?
Транзакция в процессе работы накапливает список измененных строк/блокировок (и формируемые Undo-записи) локально в памяти коннекта (тот самый TxnWriteSet), чтобы на каждый микро-апдейт не брать тяжелые глобальные локи
Не совсем понял, какие глобальные локи? Если что, то Firebird, например, берёт read-лок на метаданные таблицы (чтобы заблочить того, кто захочет поменять структуру таблицы), и этот лок лёгкий. Для записи строки берётся лок на страницу, я бы не назвал его глобальным.
Если я вас правильно понял, и write set сохраняется в момент commit-а транзакции, то, получается, сами операции со строками занимают меньше времени, а commit более тяжёлый. Вообще выглядит, что write set подходит для двух вещей: быстрый откат маленьких транзакций, и оптимизация записи нескольких строк в одну страницу.
Но давайте посмотрим со стороны движка: чтобы сделать такой гигантский DELETE, базе нужно поднять с диска кучу старых страниц, вымыв из BufferPool реально горячие данные, и сгенерировать мегабайты мусора.
Эээ почему подъём старых страниц должен вымывать из BufferPool-а горячие данные? Почему нельзя обработать страницу и сказать, что она больше не нужна, чтобы она не оставалась BufferPool ? Хотя я думаю, что Firebird так не умеет, про Postgres не скажу.
Ещё пара соображений. Некоторые разработчики современных баз данных утверждают, что SSD стали очень быстрыми, и всё это управление буферами нафиг не сдалось, оно было нужно в эру HDD. Что вы думаете об этом?
По пункту 1 не совсем понял, какая связь у транзакции и RAM-бюджета? Я бы ожидал, что транзакция обновляет страницы таблицы в кеше, который сбрасывается на диск, пишет undo-лог на диск.
Насчёт батчинга: вам будет непросто объяснить, почему вместо delete from orders where date < today - 10 вы предложите выбирать идентификаторы, нарезать их пачками и удалять, перечисляя эти идентификаторы.
Про Firebird я, похоже, недостаточно подробно описал. Там нет undo log-а в append-only виде, предыдущие версии строк размазаны в страницах той же таблицы.
С предыдущими статьями мне было сложно, там была критика существующих решений в духе "MVCC плохо, блокировки плохо". И не очень понятно, а как хорошо? Тут хоть конкретика появилась.
Я правильно понял, что txn_max_write_set_mb определяет, что в одной транзакции не получится обновить больше, чем сколько-то строк таблицы? Если так, то это очень напрягает. Я понимаю про OLTP, но даже в OLTP базе нужно делать maintenance-операции, и они бывают большими.
Я сейчас, возможно, глупости буду говорить. Я не понимаю взаимосвязи BufferPool и того, что база в одном файле. BufferPool - это же про управление ресурсами, чтобы не просить память у операционки динамически и не отдавать ей эту память обратно. Он же не хранится в файлах базы, это временные данные. Какая связь со структурой файлов базы на диске?
Насчёт "UNDO-log MVCC vs Multi-version Heap" : я знаю ещё про подход Firebird, у них не новая версия строки сохраняется в новом месте, а предыдущая копируется в новое место, а новая версия перезаписывается. Это наверняка быстрее undo log для транзакций в режиме read commited и repeatable read, но тоже требует уборки мусора.
Очень смущает, что вы используете термин "ключ декодирования", хотя сами же пишете, что в JWS нет никакого кодирования, там подпись. Объяснялка "Варианты шифрования JWT" не имеет смысла, он не шифрован. Зачем вы в verify() засунули и проверку подписи, и извлечение claims - непонятно, это два не связанных друг с другом шага. Из-за того, что не приведён код encode() и decode(), трудно проверить, чем они у вас занимаются, но должны, соответственно, формировать и проверять подпись (я потом проверил на гитхабе, это не ваши, а библиотечные функции).
За скобками осталось самое интересное: откуда брать авторизационную информацию? Это очень большая часть того же keycloak.
Вашу первую статью заплюсили не за идею, а за бодрый задиристый стиль. Он выделялся на фоне водянистых ЛЛМ-ных статей, он заряжал энергией. Именно это имели в виду под "повезло": если бы это была ваша единственная статья, то отлично бы прокатило, а если бы вы продолжили писать в этом стиле, то быстро бы надоели, и на пятый-десятый раз вас бы начали сливать.
Но вторая ваша статья была большой ошибкой. Если манипулятор сразу после акта манипуляции тут же начинает разоблачать секреты, то слабон он, а не манипулятор. Во-первых, он торопится, чтобы самому себя разоблачить прежде, чем другие это сделают. Во-вторых, у него кроме этой манипуляции никаких других нет. В третьих, жадненький он, хочет два раза заработать на одной теме. Так что никакой-то вы и не крутой оказались, мы разочарованы. И тон статьи сразу стал осторожнее, бодрость и крутизна пропала. Зато появились хвастовство про "порвал Хабр", "попал в топ", "жирные заявки". Крутые не хвастаются. Если после первой статьи ещё мог создаться ореол умного человека с глубоким пониманием, то тут уже инфоцыганская сущность была заявлена самолично. В первой статье было мало Евгения, вторая статья была главным образом о Евгении. Эта статья вам не поможет, тут вы тоже изображаете анализ, а на самом деле - слабак. Ноете про слив кармы, экая важность!
И напоследок, Евгений. Вы в комментах под второй статьёй льстили комментаторам фразами в духе "редко такое встретишь в наши дни". Вы правда верите, что это работает?
Нет, белые списки - это жалкий ответ на тот мрак, который государство создало год назад, вырубая мобильный интернет в очень большом городе, когда бумажных денег у людей с собой не было, а заплатить через СБП они не могли, такси заказать, билеты купить и посмотреть расписание не могли, без навигатора доехать не могли и были не готовы к этому. Всё кроме этого будет добавлено только за бабло.
В тоне автора чувствуется уважение к сильной руке государства и жёстким мерам. Государство большое и страшное, это да, но тупое и ленивое. Граждане, в силу эгоистических причин, выкручиваются теми сиюминутными способами, которые для них выглядят дешевле всего, и отлично отдают себе отчёт, что это всё держится на соплях и может развалиться, симки от нескольких провайдеров, пять впн-ов, анти-DPI. Менеджеры давно готовы, что сотрудник-удалёнщик в любой момент не сможет подключиться, контрагенты возвращаются к общению через SMS. На технических ресурсах делятся информацией о способах, которые работают, но автор такой: "не, школьники, вы чего, регулятор очень умный и придёт". Поскольку регулятор и государство не помогают гражданам решать их проблемы с получением информации, а только создаёт эти проблемы, то обратное давление со стороны граждан в плане выдумывания способов и их распространения - это естественно. И заходы в духе "вы слабее, а значит глупее, поэтому просто бросьте трепыхаться, а лучше любите тех, кто сильный" не возымеют никакого действия.
На второй картинке, где синусоида, грубейшая ошибка: по-горизонтали не время, а расстояние. Длина волны - это расстояние между точками с одинаковой фазой. А если по-горизонтали время рисуете, то расстояние между двумя гребнями - это период. Физики, блин.
Это вы тут недавно опубликовали одну за другой статьи на эту же тему, а потом, когда они улетели в минусы, спрятали их в черновики? Теперь третий заход?
Давайте я дам тупой пример: есть тест, который запускает всю программу, и выдаёт булевский результат: работает или не работает. Автоматизируйте исправление. Со звёздочкой: нужно не сломать то, что до исправления работало.
Для обучаемой системы важно одно - структура обратной связи.
Сильная фраза, но конечные пользователи LLM-ки не дообучают, промпт - это не дообучение.
И вот здесь у разработки есть неудобное свойство, о котором индустрия предпочитает не думать: внутри рабочего пространства она куда более детерминирована, чем кажется.
Берётся конкретное состояние репозитория. Конкретный набор ограничений. Дальше действия дают вполне осязаемые последствия. Ошибка воспроизводится или ушла.
Нейронка автора забыла упомянуть очень важное ограничение: при изменении не добавились новые ошибки. Сильно усложняет задачу, потому что в такой формулировке она перестаёт быть детерминированной. Поскольку требования для задачи задаёт кожаный, то решить проблему можно так: нейронка должна (не глюкнув, это сложно) описать изменившееся поведение системы настолько глобально, насколько вляют изменения, и кожаный должен проревьюить его (тоже не глюкнув).
И вот в чём проблема: чем лучше инженерный процесс поддаётся измерению, тем хуже он защищает ручную работу внутри себя
Я очень душный, и у меня много претензий.
не обязательно, могут и на одном. Главное, что не обязаны быть на одном и том же брокере кластера.
слово "предварительно" смущает, не нужно подписываться на топики прежде, чем сообщение будет отправлено, чтобы его получить.
Какая-то ерунда из другой оперы. Producer всегда push, consumer всегда pull. Протокол обеспечивает, что продюсер не сможет перегрузить брокера.
это внутренняя кухня протокола, разработчик на это не влияет, и аналитику до этого дела нет.
Лютая каша в формулировках.
В первом предложении в зарплату входят KPI и премии, двоеточие в языке это подразумевает. В третьем предложении премия и KPI уже процент от зарплаты. Видимо, подразумевается от базы зарплаты. Менеджер - это типа не сотрудник? Класс, который нужно создать, уже есть, он полностью соответствует требованиям. Что выделяет менеджера, и зачем это учитывать отдельно - хз, не указано.
Автор с одной стороны очень расхлябан в формулировках, а с другой - требует душнильных вещей типа SOLID и проч.
Как-то тухловато.
Во-первых, это утверждение внутренне противоречиво. Во-вторых, из того, что относится в вашей статье к науке, вы не назвали ни одной бесполезной идеи (я искренне надеюсь, что вы не считаете таковыми квантовую физику и ОТО). Так что очень странное заключение. Программирование я не считаю наукой, это инженерная практика. Нет никаких научно обоснованных эффективных техник программирования.
Да, чувствуется, что вы ориентируетесь на какие-то движки. Расскажите поподробнее, чем вы вдохновляетесь?
Не совсем понял, какие глобальные локи? Если что, то Firebird, например, берёт read-лок на метаданные таблицы (чтобы заблочить того, кто захочет поменять структуру таблицы), и этот лок лёгкий. Для записи строки берётся лок на страницу, я бы не назвал его глобальным.
Если я вас правильно понял, и write set сохраняется в момент commit-а транзакции, то, получается, сами операции со строками занимают меньше времени, а commit более тяжёлый. Вообще выглядит, что write set подходит для двух вещей: быстрый откат маленьких транзакций, и оптимизация записи нескольких строк в одну страницу.
Эээ почему подъём старых страниц должен вымывать из BufferPool-а горячие данные? Почему нельзя обработать страницу и сказать, что она больше не нужна, чтобы она не оставалась BufferPool ? Хотя я думаю, что Firebird так не умеет, про Postgres не скажу.
Ещё пара соображений. Некоторые разработчики современных баз данных утверждают, что SSD стали очень быстрыми, и всё это управление буферами нафиг не сдалось, оно было нужно в эру HDD. Что вы думаете об этом?
По пункту 1 не совсем понял, какая связь у транзакции и RAM-бюджета? Я бы ожидал, что транзакция обновляет страницы таблицы в кеше, который сбрасывается на диск, пишет undo-лог на диск.
Насчёт батчинга: вам будет непросто объяснить, почему вместо delete from orders where date < today - 10 вы предложите выбирать идентификаторы, нарезать их пачками и удалять, перечисляя эти идентификаторы.
Про Firebird я, похоже, недостаточно подробно описал. Там нет undo log-а в append-only виде, предыдущие версии строк размазаны в страницах той же таблицы.
С предыдущими статьями мне было сложно, там была критика существующих решений в духе "MVCC плохо, блокировки плохо". И не очень понятно, а как хорошо? Тут хоть конкретика появилась.
Я правильно понял, что
txn_max_write_set_mbопределяет, что в одной транзакции не получится обновить больше, чем сколько-то строк таблицы? Если так, то это очень напрягает. Я понимаю про OLTP, но даже в OLTP базе нужно делать maintenance-операции, и они бывают большими.Я сейчас, возможно, глупости буду говорить. Я не понимаю взаимосвязи BufferPool и того, что база в одном файле. BufferPool - это же про управление ресурсами, чтобы не просить память у операционки динамически и не отдавать ей эту память обратно. Он же не хранится в файлах базы, это временные данные. Какая связь со структурой файлов базы на диске?
Насчёт "UNDO-log MVCC vs Multi-version Heap" : я знаю ещё про подход Firebird, у них не новая версия строки сохраняется в новом месте, а предыдущая копируется в новое место, а новая версия перезаписывается. Это наверняка быстрее undo log для транзакций в режиме read commited и repeatable read, но тоже требует уборки мусора.
Архимеда знаю, Геродота знаю, а Бородат - он в каком веке жил?
Я правильно понял, что вы хотите сказать, что ситуация с энергией связана не с тем, что энергосистему разбомбили, а с тем, что с дронами борются?
И ещё я правильно догадываюсь, что по вашей логике эффективно в Москве вообще нахрен электричество отключать на пол дня?
Очень смущает, что вы используете термин "ключ декодирования", хотя сами же пишете, что в JWS нет никакого кодирования, там подпись. Объяснялка "Варианты шифрования JWT" не имеет смысла, он не шифрован. Зачем вы в verify() засунули и проверку подписи, и извлечение claims - непонятно, это два не связанных друг с другом шага. Из-за того, что не приведён код encode() и decode(), трудно проверить, чем они у вас занимаются, но должны, соответственно, формировать и проверять подпись (я потом проверил на гитхабе, это не ваши, а библиотечные функции).
За скобками осталось самое интересное: откуда брать авторизационную информацию? Это очень большая часть того же keycloak.
Эх, Евгений. Нифига-то вы и не поняли.
Вашу первую статью заплюсили не за идею, а за бодрый задиристый стиль. Он выделялся на фоне водянистых ЛЛМ-ных статей, он заряжал энергией. Именно это имели в виду под "повезло": если бы это была ваша единственная статья, то отлично бы прокатило, а если бы вы продолжили писать в этом стиле, то быстро бы надоели, и на пятый-десятый раз вас бы начали сливать.
Но вторая ваша статья была большой ошибкой. Если манипулятор сразу после акта манипуляции тут же начинает разоблачать секреты, то слабон он, а не манипулятор. Во-первых, он торопится, чтобы самому себя разоблачить прежде, чем другие это сделают. Во-вторых, у него кроме этой манипуляции никаких других нет. В третьих, жадненький он, хочет два раза заработать на одной теме. Так что никакой-то вы и не крутой оказались, мы разочарованы. И тон статьи сразу стал осторожнее, бодрость и крутизна пропала. Зато появились хвастовство про "порвал Хабр", "попал в топ", "жирные заявки". Крутые не хвастаются. Если после первой статьи ещё мог создаться ореол умного человека с глубоким пониманием, то тут уже инфоцыганская сущность была заявлена самолично. В первой статье было мало Евгения, вторая статья была главным образом о Евгении. Эта статья вам не поможет, тут вы тоже изображаете анализ, а на самом деле - слабак. Ноете про слив кармы, экая важность!
И напоследок, Евгений. Вы в комментах под второй статьёй льстили комментаторам фразами в духе "редко такое встретишь в наши дни". Вы правда верите, что это работает?
Нет, белые списки - это жалкий ответ на тот мрак, который государство создало год назад, вырубая мобильный интернет в очень большом городе, когда бумажных денег у людей с собой не было, а заплатить через СБП они не могли, такси заказать, билеты купить и посмотреть расписание не могли, без навигатора доехать не могли и были не готовы к этому. Всё кроме этого будет добавлено только за бабло.
В тоне автора чувствуется уважение к сильной руке государства и жёстким мерам. Государство большое и страшное, это да, но тупое и ленивое. Граждане, в силу эгоистических причин, выкручиваются теми сиюминутными способами, которые для них выглядят дешевле всего, и отлично отдают себе отчёт, что это всё держится на соплях и может развалиться, симки от нескольких провайдеров, пять впн-ов, анти-DPI. Менеджеры давно готовы, что сотрудник-удалёнщик в любой момент не сможет подключиться, контрагенты возвращаются к общению через SMS. На технических ресурсах делятся информацией о способах, которые работают, но автор такой: "не, школьники, вы чего, регулятор очень умный и придёт". Поскольку регулятор и государство не помогают гражданам решать их проблемы с получением информации, а только создаёт эти проблемы, то обратное давление со стороны граждан в плане выдумывания способов и их распространения - это естественно. И заходы в духе "вы слабее, а значит глупее, поэтому просто бросьте трепыхаться, а лучше любите тех, кто сильный" не возымеют никакого действия.
Нейростатья, нейроответы в комментариях.
Я в предыдущих сказал, эта ничем не отличается: инфоцыганство.
То есть да, вы, мне не показалось. Спрошу прямее: вы спрятали, чтобы статьи с сильно отрицательным рейтингом на сказывались на вашем статусе?
На второй картинке, где синусоида, грубейшая ошибка: по-горизонтали не время, а расстояние. Длина волны - это расстояние между точками с одинаковой фазой. А если по-горизонтали время рисуете, то расстояние между двумя гребнями - это период. Физики, блин.
Это вы тут недавно опубликовали одну за другой статьи на эту же тему, а потом, когда они улетели в минусы, спрятали их в черновики? Теперь третий заход?
чего-чего?
Этот тезис нуждается в обосновании.
Давайте я дам тупой пример: есть тест, который запускает всю программу, и выдаёт булевский результат: работает или не работает. Автоматизируйте исправление. Со звёздочкой: нужно не сломать то, что до исправления работало.
Сильная фраза, но конечные пользователи LLM-ки не дообучают, промпт - это не дообучение.
Нейронка автора забыла упомянуть очень важное ограничение: при изменении не добавились новые ошибки. Сильно усложняет задачу, потому что в такой формулировке она перестаёт быть детерминированной. Поскольку требования для задачи задаёт кожаный, то решить проблему можно так: нейронка должна (не глюкнув, это сложно) описать изменившееся поведение системы настолько глобально, насколько вляют изменения, и кожаный должен проревьюить его (тоже не глюкнув).
Да с чего бы?