У меня аналогичные ощущения от всей этой затеи с TDD. 100% покрытие кода,не гарантирует 100% правильности работы, а в сотнях и тысячах тестов будет масса ошибок, которые нужно исправлять отдельно.
При этом все типы тестов нужны и важны, если подходить разумно, а не быть абизянкой с методикой.
Простите, если можно доставить «специально для нужного объекта» обновление ОС, то зачем заморачиваться каким-то еще приложением и тайным каналом связи с аппаратной поддержкой? Не проще ли включить все необходимые инструменты анализа прямо в обновление?
Palm был в первую очередь классным благодаря Zen of Palm, это такой документ, который описывает дизайнерские решения платформы (UX в первую очередь). Дизайнеры шли от потребностей пользователя, за что им много лучей уважения.
Для того чтобы отслеживать интересы посетителей на сайтах FB убеждает сайты ставить его виджеты. Сейчас речь идет о приложениях, где на мой взгляд, скорее потребляется информация, которая была ранее собрана фейсбуком для таргетирования рекламы.
«Слежка» или Tracking это очень сильное и красивое слово, которое позволяет Apple бороться за рекламные деньги после того как её iAD не выдержал конкуренции.
На самом же деле речь идет о IDFA, который внедрил же Apple специально для рекламных целей и который позволяет рекламным сетям ассоциировать профиль пользователя с рекламными запросами. Т.е. если взять тот же facebook, то у него есть все данные, которые пользователь уже ему сообщил, он приблизительно знает его интересы и умеет таргетировать рекламу. Но есть проблема: когда юзер запускает чужое приложение с рекламным SDK от Facebook'а, то Facebook не знает, что это за пользователь, а разрешение использования IDFA в построить эту связь и показать более качественную рекламу.
Действительно, при этом Facebook будет знать, что я играю в виртуальную ферму и выращиваю огурцы. При этом в тот же Facebook пользователи добровольно отправляют гораздо более ценные данные гигабайтами.
Ну а Apple получит конкурентное преимущество в рекламе App Store Search, теперь только он может персонализировать рекламу под восторженные крики фанатов.
С точки зрения бекенда может быть, но пользователь приходит не к нему, а к некоторому сервису, проекту. Представьте себе, что вы разрабатываете аналог порнохаба, как вы считаете, комфортно ли будет пользователю проходить аутентификацию через гугль/фейсбук/ГосУслуги?
Статья правильная в том смысле, что проверка имени/пароля и связанные с этим заботы не такие уж простые вещи и для небольших проектов гораздо разумней использовать чужие решения.
Но уж очень резануло про некие правила GDPR: использование чужой аутентификации усложняет соответствии GDPR, вы ведь начинаете передавать данные пользователя третьим лицам, возможно в другую юрисдикцию со своими правилами обработки. А ответственность за все неправомерное использование этих данных будет на вас.
Посыл того, что при этом у вас появляется возможность хранить меньше персональных данных он хороший, но неверный. Если вашему проекту достаточно данных, которые передают провайдеры аутентификации, то просто не собирайте больше! По сути «спихнуть» на провайдера получается только хранения пароля.
Да, про TTL я просмотрел, он есть, но это не полное решение проблемы :) Для чего делается Mutex? Во время операции защищенной Mutex по какой-то причине доступ разрешен только одному процессу, при сбросе лока по таймауту, следующий процесс, которому будет выдан этот mutex встретит систему в промежуточном состоянии, причем в вашем решении он даже это не сумеет обнаружить.
Т.е. смысл mutex теряется.
Для взрослых же применений есть еще одна проблема — у вас все блокировки находятся у одного инстанса redis'а и проблемы с ним — это большие проблемы со всем сервисом. На эту тему было изрядно копий сломано, хотя разработчики считают, что 5 инстансов должно хватить, если я правильно помню результат той дискуссии :)
Redis очень удобный инструмент, но его нужно правильно и аккуратно использовать. Шаблон Mutex стандартный, но все немного сложнее. Что произойдет, когда $this->doSomeLogick() упадет? Да, обработка исключения или finally конечно нужна, но это не решение проблемы, т.к. падать может весь процесс/виртуальная машина, вся железка. А редис стоит у вас отдельно ведь, и блокировка у него повиснет до прихода сисадмина, чего бы хотелось избежать.
В примере Rate Limiter стоит задать время жизни ключа.
У меня аналогичные ощущения от всей этой затеи с TDD. 100% покрытие кода,не гарантирует 100% правильности работы, а в сотнях и тысячах тестов будет масса ошибок, которые нужно исправлять отдельно.
При этом все типы тестов нужны и важны, если подходить разумно, а не быть абизянкой с методикой.
Для того чтобы отслеживать интересы посетителей на сайтах FB убеждает сайты ставить его виджеты. Сейчас речь идет о приложениях, где на мой взгляд, скорее потребляется информация, которая была ранее собрана фейсбуком для таргетирования рекламы.
На самом же деле речь идет о IDFA, который внедрил же Apple специально для рекламных целей и который позволяет рекламным сетям ассоциировать профиль пользователя с рекламными запросами. Т.е. если взять тот же facebook, то у него есть все данные, которые пользователь уже ему сообщил, он приблизительно знает его интересы и умеет таргетировать рекламу. Но есть проблема: когда юзер запускает чужое приложение с рекламным SDK от Facebook'а, то Facebook не знает, что это за пользователь, а разрешение использования IDFA в построить эту связь и показать более качественную рекламу.
Действительно, при этом Facebook будет знать, что я играю в виртуальную ферму и выращиваю огурцы. При этом в тот же Facebook пользователи добровольно отправляют гораздо более ценные данные гигабайтами.
Ну а Apple получит конкурентное преимущество в рекламе App Store Search, теперь только он может персонализировать рекламу под восторженные крики фанатов.
Но уж очень резануло про некие правила GDPR: использование чужой аутентификации усложняет соответствии GDPR, вы ведь начинаете передавать данные пользователя третьим лицам, возможно в другую юрисдикцию со своими правилами обработки. А ответственность за все неправомерное использование этих данных будет на вас.
Посыл того, что при этом у вас появляется возможность хранить меньше персональных данных он хороший, но неверный. Если вашему проекту достаточно данных, которые передают провайдеры аутентификации, то просто не собирайте больше! По сути «спихнуть» на провайдера получается только хранения пароля.
Т.е. смысл mutex теряется.
Для взрослых же применений есть еще одна проблема — у вас все блокировки находятся у одного инстанса redis'а и проблемы с ним — это большие проблемы со всем сервисом. На эту тему было изрядно копий сломано, хотя разработчики считают, что 5 инстансов должно хватить, если я правильно помню результат той дискуссии :)
В примере Rate Limiter стоит задать время жизни ключа.