В примере приведен консьюмер для события, который принимает сообщение из топика, дёргает save репозитория и делает acknowledge для сообщения. Допускаем, что перед ack упало, значит сообщение не обработано, и после восстановления будет обработано повторно. Операция репозитория неидемпотентная, что и приводит к проблеме.
Предлагается принимать сообщения в Inbox. В обработчике для инбокса операция записи в инбокс уже идемпотентная, что позволяет возникающую проблему избежать.
Далее представим как изменится обработчик сообщения, который теперь берет сообщение из инбокса вместо кафки. В нем после вызова репозитория будет acknowledge в инбоксе. И аналогично существует вероятность падения между вызовами репозитория и ack инбокса. Т.е. инбокс не позволил уйти от заявленной проблемы.
Не понятно, чем именно вы недовольны - php никуда не делся, продолжает существовать и развиваться. Вы спокойно можете продолжать писать web на php с server side rendering, vanilla js. Вам никто не запрещает.
Более того, он оброс очень удачными фреймворками, посмотрите что сейчас собой представляет тот-же Laravel.
Причина появления server components очевидна, ее никто не скрывал - это performance, который нельзя получить в SPA. Вы считаете вам не нужна такая гонка за клиентский опыт, для вас performance - не конкурентное приемущество? Отлично, не пользуйтесь rsc, вас никто не заставляет, у вас есть много альтернатив.
Технологии, методологии, протоколы, языки, фреймворки, библиотеки, тулы - хоть все и позволяет делать одно и тоже, но даёт разный результат, и путь к этому результату приходится преодолевать точно разный, разной тернистости.
diff вообще не смотрят. Устанавливают сборку приложения на устройство и проверяют мануально, тыкая пальцем. Как это мержится и деплоится в прод думаю понятно - тут ничего нового нет.
Соглашусь - грустная статья. В Скраме есть выражение - to do Scrum vs pretend to do Scrum. Как раз про ситуацию, когда Скрам отождествляется с церемониями. Выполняются церемонии, а Скрама нет, и соответственно нет эффекта. Не закрепилось в чем заключается Скрам, для чего нужен, в чем заключается эффект. Но нужно признать это недостаток оригинальной литературы по Скраму. Книги в основном рекламируют платное обучение и консалтинг.
Но дело даже не в Скраме, а в том, что является артефактами работы команды и для чего они вообще нужны.
То есть вы написали свое решение, потому что redgate не умеет определять изменения обьектов в базе sql server, не умеет генерить скрипты для обьектов, скрипты миграций, не умеет подгонять код скриптов под диалект конкретной версии sql server?
Вы предлагаете новое решение, хочется видеть сравнение - какие у него преимущества по сравнению с существующим. Какие недостатки существующего решения вынудили вас разрабатывать свое.
Почему вы создаете свой тул, вместо того, чтобы пользоваться хорошо работающими более 10 лет тулами от RedGate.
Разработчик меняет схему и обьекты в базе, схемы сравниваются, генерируется миграция, в git выгружается как схема так и миграции. Вы же упоминаете RedGate, почему не пользуетесь на полную мощь и изобретаете велосипед?
После логина, в описании бесплатного оффера написано, что бесплатный лимит эквивалентен постоянно работающим 2 vcpu и 4gb ram. Не написано, что речь идёт о двух VM по 2 vcpu и 4gb ram каждая. Уточните пожалуйста.
OpenSSF - это рекомендации, вы не все написанное там используете. Там много нестрогих правил типа у репозитория должно быть менее трех админов, которые звучат логично, но в реальности не практичны. Использование signed commits не увеличивает защищенность, если есть авторизация к git server. Если требовать авторизацию пользователя на каждый коммит, то это уже снимает проблему того, что злоумышленник получил доступ к девайсу сотрудника.
ФСТЭК требует описание методики, которая гарантирует, что у вас сотрудники не добавили backdoor в релиз. Вы предлагаете написать, что signed commits в этом помогают. Попробуйте, даже интересно что они ответят.
Возникла пара вопросов по возможности реального использования, как вы предлагаете их решать?
Когда ключ пользователя скомпромитирован (или допустим у нас есть требование ротации), то происходит отзыв скомпромитированного ключа и выпуск нового. Соответственно скомпромитированный ключ удаляется на сервере. При этом все коммиты, которые есть в истории, подписанные удаленным ключем становятся Unverified. Выглядят как tampered commits, т.е. получили то, от чего защищались.
Методики коллективной разработки в git подразумевают, что в main/release branch код попадает пул-реквестом, сервер делает merge commit. Каким ключом подписывается этот коммит?
Таких требований нет. Достаточно давно была проблема, которую эта функция решала. Также как и pgp для email. Но сейчас такой проблемы нет. Это атавизм в гите. Поэтому и не понятно какую проблему вы решаете.
Причём тут ФСТЭК? вы им передаёте файлы целиком с контрольными суммами. Можно заменить на подписи, но требования нет. Авторство файлов всем безразлично. Это проблема юрлица заниматься отчужденим прав от разработчиков в свой адрес.
Если вы настраиваете внутреннее окружение для разработки, соответствующее требованиям, то вам требуется контролировать пользовательские девайсы, пользовательский доступ к ним, и доступ этих пользователей к репозиториям. Подписи коммитов вам в этом никак не помогают. Не имеет никакого значения какой git user какой коммит сделал.
То есть вам требуется защита от того, что в компании один действующий сотрудник с доступом к репозиторию делает комиты выдавая себя за другого действующего сотрудника с доступом?
Конечно, давайте посмотрим на реализацию.
В примере приведен консьюмер для события, который принимает сообщение из топика, дёргает save репозитория и делает acknowledge для сообщения. Допускаем, что перед ack упало, значит сообщение не обработано, и после восстановления будет обработано повторно. Операция репозитория неидемпотентная, что и приводит к проблеме.
Предлагается принимать сообщения в Inbox. В обработчике для инбокса операция записи в инбокс уже идемпотентная, что позволяет возникающую проблему избежать.
Далее представим как изменится обработчик сообщения, который теперь берет сообщение из инбокса вместо кафки. В нем после вызова репозитория будет acknowledge в инбоксе. И аналогично существует вероятность падения между вызовами репозитория и ack инбокса. Т.е. инбокс не позволил уйти от заявленной проблемы.
Для чего в next.js потребовался "API-слой с контроллерами, сервисами и процедурами"?
Вы разбирались, что именно стало быстрее и по какой причине?
Почему вы выбрали путь написать cli tool, а не skill или plugin для существующих агентов?
Не понятно, чем именно вы недовольны - php никуда не делся, продолжает существовать и развиваться. Вы спокойно можете продолжать писать web на php с server side rendering, vanilla js. Вам никто не запрещает.
Более того, он оброс очень удачными фреймворками, посмотрите что сейчас собой представляет тот-же Laravel.
Причина появления server components очевидна, ее никто не скрывал - это performance, который нельзя получить в SPA. Вы считаете вам не нужна такая гонка за клиентский опыт, для вас performance - не конкурентное приемущество? Отлично, не пользуйтесь rsc, вас никто не заставляет, у вас есть много альтернатив.
Технологии, методологии, протоколы, языки, фреймворки, библиотеки, тулы - хоть все и позволяет делать одно и тоже, но даёт разный результат, и путь к этому результату приходится преодолевать точно разный, разной тернистости.
diff вообще не смотрят. Устанавливают сборку приложения на устройство и проверяют мануально, тыкая пальцем. Как это мержится и деплоится в прод думаю понятно - тут ничего нового нет.
Соглашусь - грустная статья. В Скраме есть выражение - to do Scrum vs pretend to do Scrum. Как раз про ситуацию, когда Скрам отождествляется с церемониями. Выполняются церемонии, а Скрама нет, и соответственно нет эффекта. Не закрепилось в чем заключается Скрам, для чего нужен, в чем заключается эффект. Но нужно признать это недостаток оригинальной литературы по Скраму. Книги в основном рекламируют платное обучение и консалтинг.
Но дело даже не в Скраме, а в том, что является артефактами работы команды и для чего они вообще нужны.
Так все блоги по sql server в этих статьях...
Конечно такие изменения делаются под нагрузкой. А какие другие варианты? Только построение индексов по смигрированным данным может занимать сутки.
То есть вы написали свое решение, потому что redgate не умеет определять изменения обьектов в базе sql server, не умеет генерить скрипты для обьектов, скрипты миграций, не умеет подгонять код скриптов под диалект конкретной версии sql server?
Грустно это, что сказать...
Вы предлагаете новое решение, хочется видеть сравнение - какие у него преимущества по сравнению с существующим. Какие недостатки существующего решения вынудили вас разрабатывать свое.
Почему вы создаете свой тул, вместо того, чтобы пользоваться хорошо работающими более 10 лет тулами от RedGate.
Разработчик меняет схему и обьекты в базе, схемы сравниваются, генерируется миграция, в git выгружается как схема так и миграции. Вы же упоминаете RedGate, почему не пользуетесь на полную мощь и изобретаете велосипед?
После логина, в описании бесплатного оффера написано, что бесплатный лимит эквивалентен постоянно работающим 2 vcpu и 4gb ram. Не написано, что речь идёт о двух VM по 2 vcpu и 4gb ram каждая. Уточните пожалуйста.
OpenSSF - это рекомендации, вы не все написанное там используете. Там много нестрогих правил типа у репозитория должно быть менее трех админов, которые звучат логично, но в реальности не практичны. Использование signed commits не увеличивает защищенность, если есть авторизация к git server. Если требовать авторизацию пользователя на каждый коммит, то это уже снимает проблему того, что злоумышленник получил доступ к девайсу сотрудника.
ФСТЭК требует описание методики, которая гарантирует, что у вас сотрудники не добавили backdoor в релиз. Вы предлагаете написать, что signed commits в этом помогают. Попробуйте, даже интересно что они ответят.
Возникла пара вопросов по возможности реального использования, как вы предлагаете их решать?
Когда ключ пользователя скомпромитирован (или допустим у нас есть требование ротации), то происходит отзыв скомпромитированного ключа и выпуск нового. Соответственно скомпромитированный ключ удаляется на сервере. При этом все коммиты, которые есть в истории, подписанные удаленным ключем становятся Unverified. Выглядят как tampered commits, т.е. получили то, от чего защищались.
Методики коллективной разработки в git подразумевают, что в main/release branch код попадает пул-реквестом, сервер делает merge commit. Каким ключом подписывается этот коммит?
Таких требований нет. Достаточно давно была проблема, которую эта функция решала. Также как и pgp для email. Но сейчас такой проблемы нет. Это атавизм в гите. Поэтому и не понятно какую проблему вы решаете.
Причём тут ФСТЭК? вы им передаёте файлы целиком с контрольными суммами. Можно заменить на подписи, но требования нет. Авторство файлов всем безразлично. Это проблема юрлица заниматься отчужденим прав от разработчиков в свой адрес.
Если вы настраиваете внутреннее окружение для разработки, соответствующее требованиям, то вам требуется контролировать пользовательские девайсы, пользовательский доступ к ним, и доступ этих пользователей к репозиториям. Подписи коммитов вам в этом никак не помогают. Не имеет никакого значения какой git user какой коммит сделал.
То есть вам требуется защита от того, что в компании один действующий сотрудник с доступом к репозиторию делает комиты выдавая себя за другого действующего сотрудника с доступом?
Да, MASS потрясающий тул.
Непонятно как вы сравнивайте ISO vs PXE, если PXE это посути способ доставки ISO. Как ваш ISO появляется на сервере, чтобы он мог с него загрузится?