Анти‑Agile акцентирует внимание на том, чтобы в начале проекта были зафиксированы четкие требования, что минимизирует вероятность изменений в будущем.
Если у вас есть четкие требования в самом начале, которые гарантировано не будут меняться, Agile вам не нужен. Беда лишь в том, что такая ситуация - относительная редкость. Соответственно приходится придумывать что-то, когда точно известно только одно - требования будут меняться.
В Agile команды работают над небольшими итерациями и могут менять направление в зависимости от фидбэка. В анти‑Agile акцент делается на планировании всей работы заранее.
По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.
Остальные утверждения - очень спорные.
Agile поощряет изменения и адаптацию, тогда как анти‑Agile требует строгого следования заранее установленным процессам и графикам.
Нет.
В Agile очень строгий метапроцесс - процесс непрерывных измерений и улучшений. Все производные процессы от главного метапроцесса (сбор требований, разработка, тестирование, и т.д.) - да, адаптируются. Но метапроцесс - очень формализован. И отказ от его формализованности влечет за собой все проблемы аджайла.
Agile подразумевает, что команды сами определяют, как работать, тогда как в анти‑Agile каждая команда имеет четко определенные роли и обязанности.
Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.
Когда у вас микросервисы, и хочется иметь одну точку управления схемами со всех микросервисов. Вот тогда, да, GraphQL проявляется во всей красе. Правда не достается бесплатно, есть свои ограничения.
Если у вас один сервис, то особого преимущества REST vs GQL нет.
Сертификат пользователя («фактор владения», расположен в хранилище сертификатов компьютера пользователя, можно сделать не экспортируемым)
Фактор владения приватным ключом!
Сертификат всего лишь свидетельство владения приватным ключом, в котором указано кому выдано свидетельство и кем. У сертификата не может быть фактора владения, т.к. сертификаты публичны.
В относительно простых процессах, без большой нагрузки, без требований по доступности, без требований по TTM, (критерии можно дальше продолжать) - Camunda вполне ок.
Если любой из критерием выше не выполняется - я сегодня Camunda'у из списка вычеркну.
Это не значит, что Camunda не может нагрузку держать. Если ее долго и мучительно тюнить - вполне может. Правда в этот момент приходит осознание, что без Camunda'ы во втором случае было бы легче, но выпиливать ее уже никто не даст, кучу усилий закопали в ее тюнинг.
вы сейчас про работу приложения на устройстве пользователя, к аутентификации на удаленном сервисе это никакого отношения не имеет.
в общем случае, да, было бы хорошо контролировать целостность софта на устройстве пользователя. но задача, опять же в общем случае, нерешаема, т.к. устройство контролирует только сам пользователь. нет никаких надежных способов ограничивать доступ к устройству. sony ps и iphone ломают несмотря на серьезные усилия производителей.
Встречал реализации, где для аутентификации вместо подписи отправлялся сертификат.
Т.е. аутентификация осуществлялась по предъявлению сертификата ;)))
зы
еще встречал реализации подписи файла, где подписывалось уникальное имя файла, а не содержимое файла. и авторы такого подхода утверждали, что все ок, т.к. имя файла уникально и секретно, а-ля хеш файла ;))
Я понимаю, что сейчас мода на бд-кластеры. Примерно как kafka, пихают везде где только можно.
Абсолютное большинство проектов, которые я видел за последние лет 5, совсем не требовали кластерных бд. Не было таких бизнес-требований. Это с одной стороны.
С другой, часть кластеров не обеспечивала своей первичной функции - доступность кластера при недоступности одной из нод. Т.е. кластер развернули, но не протестили, или протестили, но не осилили пофиксить проблему.
С третьей, большинство проектов разворачивали кластер на одной, ну или на двух физических железках. Очевидно, при падении железки все ноды кластера тоже падают. Понимания, что для кластеров нужно минимум три физических железки есть у очень редких спецов.
Сторипоинты у разработчиков, это примерно как кубометры кирпичной кладки у каменщиков.
Сторипоинты, (и прочие измерения, типа маек) появились, т.к. у разработчиков отсутствуют простые способы измерения результатов их работ. Вследствие этого, сторипоинты не идеальны, в сравнении в кубометрами кладки, увы.
Чем плохо мерить в часах?
Тем же, что каменщиков мерить в человеко-часах. У каменщиков разная производительность. Один и тот же объем будет сделан за разное время. Поэтому оцениваем объем в кубометрах (в ит - сложность задачи в сторипоинтах). Потом с учетом производительности конкретных исполнителей можно получить затраты времени.
Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
да нет никаких чудес, идемпотентность - это только один нюансов.
надежная платежная логика основана на локах. есть некоторые частные случаи, когда можно обойтись без локов, в обмен на ... (и тут разные опции).
Я видел множество инсталляций SQL Server, которые были развернуты неспециалистами, и просто работали.
Я видел множество инсталляций Postgres, которые были развернуты неспециалистами, и просто работали.
Но почти не видел инсталляций Oracle (Express не беру в расчет), имхо как раз Oracle требуется внимание спеца, начиная с этапа развертывания.
Единственное справедливое утверждение:
Если у вас есть четкие требования в самом начале, которые гарантировано не будут меняться, Agile вам не нужен. Беда лишь в том, что такая ситуация - относительная редкость. Соответственно приходится придумывать что-то, когда точно известно только одно - требования будут меняться.
По сути следствие предыдущего утверждения. Да, если требования зафиксированы, можно запланировать весь скоуп и далее просто бежать по нему.
Остальные утверждения - очень спорные.
Нет.
В Agile очень строгий метапроцесс - процесс непрерывных измерений и улучшений. Все производные процессы от главного метапроцесса (сбор требований, разработка, тестирование, и т.д.) - да, адаптируются. Но метапроцесс - очень формализован. И отказ от его формализованности влечет за собой все проблемы аджайла.
Agile декларирует, что ответственность команды за конкретный сервис должна быть всеобъемлющей. Отсюда и проистекает некоторая вторичность ролей. Т.е. условно бекендер или тестировщик не могут сказать - я не могу запрофилировать sql-запрос, это не моя проф.область, поэтому чтобы решить проблему ищите ДБА. На сервисе есть проблема - команда без оглядки на свои роли, ищет решение.
Вся преимущество GraphQL в федерации.
Когда у вас микросервисы, и хочется иметь одну точку управления схемами со всех микросервисов. Вот тогда, да, GraphQL проявляется во всей красе. Правда не достается бесплатно, есть свои ограничения.
Если у вас один сервис, то особого преимущества REST vs GQL нет.
Неделя войны микрорепа vs монорепа объявляется открытой!
Фактор владения приватным ключом!
Сертификат всего лишь свидетельство владения приватным ключом, в котором указано кому выдано свидетельство и кем. У сертификата не может быть фактора владения, т.к. сертификаты публичны.
Я бы сказал, наоборот.
В относительно простых процессах, без большой нагрузки, без требований по доступности, без требований по TTM, (критерии можно дальше продолжать) - Camunda вполне ок.
Если любой из критерием выше не выполняется - я сегодня Camunda'у из списка вычеркну.
Это не значит, что Camunda не может нагрузку держать. Если ее долго и мучительно тюнить - вполне может. Правда в этот момент приходит осознание, что без Camunda'ы во втором случае было бы легче, но выпиливать ее уже никто не даст, кучу усилий закопали в ее тюнинг.
Расскажите, какие есть способы контроля целостности ПО на устройстве пользователя, которым может доверять удаленный сервис?
вы сейчас про работу приложения на устройстве пользователя, к аутентификации на удаленном сервисе это никакого отношения не имеет.
в общем случае, да, было бы хорошо контролировать целостность софта на устройстве пользователя. но задача, опять же в общем случае, нерешаема, т.к. устройство контролирует только сам пользователь. нет никаких надежных способов ограничивать доступ к устройству. sony ps и iphone ломают несмотря на серьезные усилия производителей.
ITIL и COBIT?
Это что.... ;)))
Встречал реализации, где для аутентификации вместо подписи отправлялся сертификат.
Т.е. аутентификация осуществлялась по предъявлению сертификата ;)))
зы
еще встречал реализации подписи файла, где подписывалось уникальное имя файла, а не содержимое файла. и авторы такого подхода утверждали, что все ок, т.к. имя файла уникально и секретно, а-ля хеш файла ;))
не надо.
достаточно проверять валидность подписи, и валидность сертификата(-ов), включая полномочия.
Выше странный спор, что выгоднее.
Все равно, что спорить, что выгоднее: своя машина, каршеринг или такси.
В зависимости от контекста, может быть выгоднее любая из опций. Это относительно легко считается и принимается решение.
Я понимаю, что сейчас мода на бд-кластеры. Примерно как kafka, пихают везде где только можно.
Абсолютное большинство проектов, которые я видел за последние лет 5, совсем не требовали кластерных бд. Не было таких бизнес-требований. Это с одной стороны.
С другой, часть кластеров не обеспечивала своей первичной функции - доступность кластера при недоступности одной из нод. Т.е. кластер развернули, но не протестили, или протестили, но не осилили пофиксить проблему.
С третьей, большинство проектов разворачивали кластер на одной, ну или на двух физических железках. Очевидно, при падении железки все ноды кластера тоже падают. Понимания, что для кластеров нужно минимум три физических железки есть у очень редких спецов.
🤦♂️
Строго говоря, XML тоже не всегда читается из clob поля в том же виде что и был при записи. Когда это принципиально важно, приходится писать в blob.
А если используется blob, то и json туда же можно писать.
Да, postgres не сможет из такого поля условия применять. Но, как всегда, приходится выбирать....
Говорят, если SM перевести на Kotlin DSL, то и разрабы улетают в космос вместе со стульями
Сторипоинты у разработчиков, это примерно как кубометры кирпичной кладки у каменщиков.
Сторипоинты, (и прочие измерения, типа маек) появились, т.к. у разработчиков отсутствуют простые способы измерения результатов их работ. Вследствие этого, сторипоинты не идеальны, в сравнении в кубометрами кладки, увы.
Чем плохо мерить в часах?
Тем же, что каменщиков мерить в человеко-часах. У каменщиков разная производительность. Один и тот же объем будет сделан за разное время. Поэтому оцениваем объем в кубометрах (в ит - сложность задачи в сторипоинтах). Потом с учетом производительности конкретных исполнителей можно получить затраты времени.
Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
И условно старый gradle процентов на 80 декларативный.
Дефолтный конфиг обычно выглядит как список плагинов, список репозитариев и список зависимостей. Это в чистом виде декларативность.
Я тоже практически всю жизнь скептически смотрел на mysql.
Пока в силу обстоятельстве в одном HL, HA проекте не был использован Oracle MySql 8
С тех пор кардинально изменил мнение об mysql в частности. И какой либо технологии в общем.
зы
у mysql - вагон форков, возможно далеко не все форки хороши. моя оценка про оракловый mysql
легко