Вот интересный шаблон недружественного поведения приложения, которого можно было бы легко избежать, если бы программисты и бизнесмены рассуждали как обычные люди.
У меня есть звуковая система Pioneer/Onkyo. Это неплохая техника, которая поставляется с (не слишком дерьмовым) Android-приложением для дистанционного управления.
Однажды приложение обновилось и показало стандартный журнал изменений c «исправлениями ошибок и улучшениями», но при открытии выскочило это:
Как вам очевидно известно, RBAC — это управление доступом на основе ролей. Все, кто создавали системы чуть большие чем домашняя страничка и чуть меньшие чем Госуслуги, задумывались о том, как разграничить права пользователей.
В этой статье я не буду рассказывать о том, что такое RBAC и почему это хорошо (хотя немного, конечно, расскажу), а познакомлю вас со своей скромной разработкой (h-rbac) и попытаюсь объяснить, почему она по некоторым аспектам лучше, чем известные "монстры".
Автор этой статьи — Бренден Маллиган, один из создателей LaunchKit, пакета инструментов для iOS-разработчиков. Он также работает над мобильным и веб-приложением Cluster, которое позволяет создавать личные соцсети на основе общих интересов и опыта. Также Бренден является автором проектов ArtistData и OneSheet.
Cluster стал моим первым мобильным нативным приложением. Работая над ним, я научился многому, в том числе и не относящемуся к сети. Создавая веб-приложение, вы всего лишь делаете страницу для посетителей. Но когда вы разрабатываете нативное приложение, то не просто предлагаете людям что-то скачать, но и, скорее всего, спрашиваете у них доступ к их местоположению или личным данным. А это отношения уже совсем иного рода.
Главный урок, который я вынес: не запрашивайте у пользователей доступ до тех пор, пока данные вам действительно не понадобится. И предельно ясно дайте им понять, что они получат взамен.
Читать полностью »
