вы сейчас про работу приложения на устройстве пользователя, к аутентификации на удаленном сервисе это никакого отношения не имеет.
в общем случае, да, было бы хорошо контролировать целостность софта на устройстве пользователя. но задача, опять же в общем случае, нерешаема, т.к. устройство контролирует только сам пользователь. нет никаких надежных способов ограничивать доступ к устройству. sony ps и iphone ломают несмотря на серьезные усилия производителей.
Встречал реализации, где для аутентификации вместо подписи отправлялся сертификат.
Т.е. аутентификация осуществлялась по предъявлению сертификата ;)))
зы
еще встречал реализации подписи файла, где подписывалось уникальное имя файла, а не содержимое файла. и авторы такого подхода утверждали, что все ок, т.к. имя файла уникально и секретно, а-ля хеш файла ;))
Я понимаю, что сейчас мода на бд-кластеры. Примерно как kafka, пихают везде где только можно.
Абсолютное большинство проектов, которые я видел за последние лет 5, совсем не требовали кластерных бд. Не было таких бизнес-требований. Это с одной стороны.
С другой, часть кластеров не обеспечивала своей первичной функции - доступность кластера при недоступности одной из нод. Т.е. кластер развернули, но не протестили, или протестили, но не осилили пофиксить проблему.
С третьей, большинство проектов разворачивали кластер на одной, ну или на двух физических железках. Очевидно, при падении железки все ноды кластера тоже падают. Понимания, что для кластеров нужно минимум три физических железки есть у очень редких спецов.
Сторипоинты у разработчиков, это примерно как кубометры кирпичной кладки у каменщиков.
Сторипоинты, (и прочие измерения, типа маек) появились, т.к. у разработчиков отсутствуют простые способы измерения результатов их работ. Вследствие этого, сторипоинты не идеальны, в сравнении в кубометрами кладки, увы.
Чем плохо мерить в часах?
Тем же, что каменщиков мерить в человеко-часах. У каменщиков разная производительность. Один и тот же объем будет сделан за разное время. Поэтому оцениваем объем в кубометрах (в ит - сложность задачи в сторипоинтах). Потом с учетом производительности конкретных исполнителей можно получить затраты времени.
Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
Только один комментарий. Микросервисы - это не про технологии, микросервисы - это про бизнес, про способ организации работы большого количества разработчиков. И основной значимый критерий сервис микро или нет - одна ИТ команда (5-7 человеков) полностью отвечает за сервис, от разработки до сопровождения. Работает плохо этот сервис? Только эта команда его чинит.
Является ли микросервис - подой в кубере или OSGI-модулем в большом java-приложении - в общем случае неважно. Хотя в экстремуме микросервис должен обладать своими собственными ресурсами, которые никакой другой сервис забрать не может.
1) большого проекта с большим количеством провайдеров данных и нескольких фронтов (например, пара мобилок, веб-десктоп, терминал - все они похожи, но у каждого свои нюансы)
2) команда(-ы) хорошо знает GraphQL в принципе, тогда можно использовать и на более мелких проектах, но основанных на микросервисах.
GraphQL, очевидно, не панацея, и как любую другую технологию надо использовать с умом. И как любая другая технология, при использовании с умом - приносит только пользу.
Теперь, проектируя интерфейсы для фронта вы будете знать, что на фронте есть не только время, но и таймзона. И время с бека нужно отдавать/принимать с таймзоной. Фронт в свою очередь, должен работать с этим с учетом своей локали. Так надо делать всегда.
А вот надо ли хранить время в бд вместе с таймзоной - вопрос открытый.
И оба вопроса хоть и пересекаются между собой, но друг другу не мешают.
утверждение: "всегда хранить время c таймзоной", тоже может создавать нетривиальные проблемы.
например, изменение таймзоны в конкретной географической точке.
и тогда получается, что события сохраненные вчера в 17ч (+3), сегодня эти же события стали 16ч (+2), потому что сегодня ночью таймзона сменилась.
вообще, в случае микросервисов, и взаимодействия бд только с одним приложением, проблема с таймзоной внутри бд перестает быть актуальной. конкретное приложение становится ответственным за правильную работу с таймзоной. и соответственно можно хранить время в бд без таймзоны.
Расскажите, какие есть способы контроля целостности ПО на устройстве пользователя, которым может доверять удаленный сервис?
вы сейчас про работу приложения на устройстве пользователя, к аутентификации на удаленном сервисе это никакого отношения не имеет.
в общем случае, да, было бы хорошо контролировать целостность софта на устройстве пользователя. но задача, опять же в общем случае, нерешаема, т.к. устройство контролирует только сам пользователь. нет никаких надежных способов ограничивать доступ к устройству. 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
легко
В целом с большинством тезисов согласен.
Только один комментарий. Микросервисы - это не про технологии, микросервисы - это про бизнес, про способ организации работы большого количества разработчиков. И основной значимый критерий сервис микро или нет - одна ИТ команда (5-7 человеков) полностью отвечает за сервис, от разработки до сопровождения. Работает плохо этот сервис? Только эта команда его чинит.
Является ли микросервис - подой в кубере или OSGI-модулем в большом java-приложении - в общем случае неважно. Хотя в экстремуме микросервис должен обладать своими собственными ресурсами, которые никакой другой сервис забрать не может.
Свои сборки jdk есть у многих крупных компаний Китая и Европы.
И не только jdk.
Camunda 8-й версии научилась "из коробки" не выпадать в осадок, если вызываемые синхронные сервисы замедлились или таймаутят?
GraphQL окупается в случае:
1) большого проекта с большим количеством провайдеров данных и нескольких фронтов (например, пара мобилок, веб-десктоп, терминал - все они похожи, но у каждого свои нюансы)
2) команда(-ы) хорошо знает GraphQL в принципе, тогда можно использовать и на более мелких проектах, но основанных на микросервисах.
GraphQL, очевидно, не панацея, и как любую другую технологию надо использовать с умом. И как любая другая технология, при использовании с умом - приносит только пользу.
Есть БД, которые умеют хранить время с регионом таймзоны в одном поле?
Это просто опыт.
Теперь, проектируя интерфейсы для фронта вы будете знать, что на фронте есть не только время, но и таймзона. И время с бека нужно отдавать/принимать с таймзоной. Фронт в свою очередь, должен работать с этим с учетом своей локали. Так надо делать всегда.
А вот надо ли хранить время в бд вместе с таймзоной - вопрос открытый.
И оба вопроса хоть и пересекаются между собой, но друг другу не мешают.
даже больше скажу.
утверждение: "всегда хранить время c таймзоной", тоже может создавать нетривиальные проблемы.
например, изменение таймзоны в конкретной географической точке.
и тогда получается, что события сохраненные вчера в 17ч (+3), сегодня эти же события стали 16ч (+2), потому что сегодня ночью таймзона сменилась.
вообще, в случае микросервисов, и взаимодействия бд только с одним приложением, проблема с таймзоной внутри бд перестает быть актуальной. конкретное приложение становится ответственным за правильную работу с таймзоной. и соответственно можно хранить время в бд без таймзоны.