Даже для такой странной цели, как трансляция чего-либо в пестуемый автором AsmX, есть куда более подходящие инструменты. Тот же chevrotain справится куда лучше.
Ну кроме самих изменений хочется хранить еще мета-информацию о статусе синхронизации. Скажем, в табличку я могу докинуть поле, которое отражает успешно ли сообщение отправлено брокеру или нет, время последней попытки, еще какие-то связанные метрики, и т.д. В случае с WAL-логом сложно будет обеспечить дискретность сообщений - придётся всё равно где-то state хранить.
Опять же с табличкой есть вариант делать оркестрацию на самом сервисе, а если у вас WAL вычитывает кто-то еще, то да, хореография с сагами скорее всего неизбежны.
PS: transactional outbox можно запилить не только на триггерах. Для такого паттерна мы используем возможности ORM'ки - в хуках транзакция не закрыта и можно докинуть в неё нужные SQL выражения.
CDC через чтение WAL лога не позволяет обеспечить транзакционность между изменением и уведомлением об этом изменении. К примеру, мы хотим всегда быть уверены что при изменении записи в исходной базе, мы успешно отразим это в другом сервисе. И если это не получилось сделать, то нужно откатить исходное изменение. Transactional outbox в данном случае куда применимее.
Косяки-то объективные. Топят мелких производителей из-за своих ошибок, недостоверные данные тестов, аффилированность с рядом компаний. Тот же Стив делает контент более качественно, пусть и в меньших масштабах.
Тема интересная, но для аудио/видео формата мало подходит. Даже если это будет не подкаст, а какой-то монтаж, то придётся хронометраж растягивать и какие-то пояснения/иллюстрации на экране показывать.
Набор - да, но отличается порядок. В одном случае в стеке по смещению X лежит, скажем, r10, а в другой либе - r15. Вам я думаю это не так важно пока frame pointer во всех реализациях лежит по одинаковому смещению (а логично его сверху стека класть). Но вот если собирать еще и контекст нити, то разница может проявиться.
Для меня не так очевидно :) В первом случае "rbp, rbx, r15, r14, r13, r12", во втором "rbp, rbx, r12, r13, r14, r15". PS: просто глянул подсвеченные куски кода без внимательного чтения сорцов.
Насчет хранения контрактов - у себя сделали просто: контракт в репозитории провайдера является источником правды, но у нас есть хук, который вызывается когда контракт обновляется, и который копирует его в центральный репозиторий.
Насколько я вижу, параметры сложно выбрать эмпирически - размер структуры второго уровня будет варироваться от входных данных (а точнее, от хэша по этим данным). Мб тогда стоит какую-то подстройку на основе статистики иметь? Метрики, конечно, полезно (включая добавленную метрику по коллизиям), но думаю прикольно чтоб тулза сама подсказывала оптимальные параметры.
Прежде чем переключился на восхождения, совершил несколько треккингов, которые могу советовать - gr20 на корсике, overland trek в тасмании, laugavegur в исландии и, конечно же, непал и альпы. Это не автономка, но треки весьма интересны.
Планировал переехать в Словению, но стоимость оформления ВНЖ слишком высока - через бизнес нужно отстегивать по 1000 евро в месяц на поддержание ооо'шки с минималкой налогов. Через аутстафф еще выше.
PS: автор забыл упомянуть проблему с покупкой недвижимости не-гражданами страны.
Вода водой и возникает вопрос к экспертизе автора - насколько у него большой опыт в индустрии, чтобы он мог делать выводы по ситуации в целом. Скорее всего как обычно - поработал в небольшом числе компаний на рядовой должности, но рассуждает о том, как устроен рынок.
PS: судоку настолько затёртая тема, что завидовать нечему :) Я малость в теме, и классические судоку уже давно (лет 10) не в тренде - на большинстве гран-при решают модификации паззла с дополнительными ограничениями.
Даже для такой странной цели, как трансляция чего-либо в пестуемый автором AsmX, есть куда более подходящие инструменты. Тот же chevrotain справится куда лучше.
Ну кроме самих изменений хочется хранить еще мета-информацию о статусе синхронизации. Скажем, в табличку я могу докинуть поле, которое отражает успешно ли сообщение отправлено брокеру или нет, время последней попытки, еще какие-то связанные метрики, и т.д. В случае с WAL-логом сложно будет обеспечить дискретность сообщений - придётся всё равно где-то state хранить.
Опять же с табличкой есть вариант делать оркестрацию на самом сервисе, а если у вас WAL вычитывает кто-то еще, то да, хореография с сагами скорее всего неизбежны.
PS: transactional outbox можно запилить не только на триггерах. Для такого паттерна мы используем возможности ORM'ки - в хуках транзакция не закрыта и можно докинуть в неё нужные SQL выражения.
CDC через чтение WAL лога не позволяет обеспечить транзакционность между изменением и уведомлением об этом изменении. К примеру, мы хотим всегда быть уверены что при изменении записи в исходной базе, мы успешно отразим это в другом сервисе. И если это не получилось сделать, то нужно откатить исходное изменение. Transactional outbox в данном случае куда применимее.
Косяки-то объективные. Топят мелких производителей из-за своих ошибок, недостоверные данные тестов, аффилированность с рядом компаний. Тот же Стив делает контент более качественно, пусть и в меньших масштабах.
Обычно этот алгоритм называют именем Карацубы - https://en.wikipedia.org/wiki/Karatsuba_algorithm.
Ну и есть еще более быстрые алоритмы для больших![n]()
.
Тема интересная, но для аудио/видео формата мало подходит. Даже если это будет не подкаст, а какой-то монтаж, то придётся хронометраж растягивать и какие-то пояснения/иллюстрации на экране показывать.
Набор - да, но отличается порядок. В одном случае в стеке по смещению X лежит, скажем, r10, а в другой либе - r15. Вам я думаю это не так важно пока frame pointer во всех реализациях лежит по одинаковому смещению (а логично его сверху стека класть). Но вот если собирать еще и контекст нити, то разница может проявиться.
Для меня не так очевидно :)
В первом случае "rbp, rbx, r15, r14, r13, r12", во втором "rbp, rbx, r12, r13, r14, r15".
PS: просто глянул подсвеченные куски кода без внимательного чтения сорцов.
Формат сохраненных состояний fiber'ов же зависит от рантайма и используемой либы, не?
PS: DWARF на win-машинках куда менее распростанён, хотя вроде как и никто не мешает закинуть DWARF-секцию в PE.
Насчет хранения контрактов - у себя сделали просто: контракт в репозитории провайдера является источником правды, но у нас есть хук, который вызывается когда контракт обновляется, и который копирует его в центральный репозиторий.
Насколько я вижу, параметры сложно выбрать эмпирически - размер структуры второго уровня будет варироваться от входных данных (а точнее, от хэша по этим данным). Мб тогда стоит какую-то подстройку на основе статистики иметь? Метрики, конечно, полезно (включая добавленную метрику по коллизиям), но думаю прикольно чтоб тулза сама подсказывала оптимальные параметры.
То есть у вас нет единого реестра схем, а каждый сервис имеет контракты как пордьсер и консьюмер?
https://tinyurl.com/chilly-regconflict - не совсем то, но концепция несколько похожая. Итеративное решение.
Тоже когда-то писал свой BIOS :) Тогда кроме coreboot'a очень помогли статьи Pinczakko's Guide to BIOS Reverse Engineering.
2-фазовые коммиты, всё как мы любим =)
Ну 7 дней это не такие уж и длительные походы)
Прежде чем переключился на восхождения, совершил несколько треккингов, которые могу советовать - gr20 на корсике, overland trek в тасмании, laugavegur в исландии и, конечно же, непал и альпы. Это не автономка, но треки весьма интересны.
Планировал переехать в Словению, но стоимость оформления ВНЖ слишком высока - через бизнес нужно отстегивать по 1000 евро в месяц на поддержание ооо'шки с минималкой налогов. Через аутстафф еще выше.
PS: автор забыл упомянуть проблему с покупкой недвижимости не-гражданами страны.
Вода водой и возникает вопрос к экспертизе автора - насколько у него большой опыт в индустрии, чтобы он мог делать выводы по ситуации в целом. Скорее всего как обычно - поработал в небольшом числе компаний на рядовой должности, но рассуждает о том, как устроен рынок.
PS: судоку настолько затёртая тема, что завидовать нечему :) Я малость в теме, и классические судоку уже давно (лет 10) не в тренде - на большинстве гран-при решают модификации паззла с дополнительными ограничениями.
Меня как и автора тоже смутил обратный flamegraph :)
Ну во флеймграфе только половина от процессинга входной картинки - распаковка png, остальное выглядит как раз как копирование байтиков туда/обратно.
А так да, достойный результат. Сам сейчас сижу профилирую всякие штуки, жаль что не приметил соревнование)