S0ER

Идея простая - есть одна основная ветка (trunk) весь код непрерывно сливается в нее, чтобы отсечь неработоспособные фичи (те фичи, которые находятся в разработке) используются флаги. Таким образом мы постоянно ревьюим код через Pull Request, а фичу включаем через флаг когда она готова.

на изображении схематично показан алгоритм работы trunk flow, из плюсов: - простой и легкий - подходит для частых релизов и CI - не имеет проблем "длинных" слияний (когда ветка долго в разработке находится)

Если меня попросят порекомендовать flow для разработки проекта, то пожалуй это будет Trunk based + Feature flag + Branch by abstraction

Вывод: ML - это конкретно методы обработки данных (в том числе и интеллектуальные), а DS - это общее направление, в которое входит весь спектр решения задач по обработке, хранению и визуализации данных.

ML же занимается: - обучением с подкреплением - компьютерным зрением - Deep Lerning - системами рекомендаци - обучением с учителем - обучением без учителя - и т.д.

Т.е. ML - это одно из направлений DS.

В решении своих задач DS, если смотреть обобщенно, использует: - Визуализацию - Хранение данных - Структурирование данных - Математические методы - Языки программирования - Решения для машинной обработки данных (ML)

Частенько встает вопрос о различии ML и DS, эта картинка хорошо показывает и различия, и состояние дел на сегодняшний день.

Современное состояние Data Science

Эта модель затрудняет статический анализ, например, сложно выдать список пользователей с необходимыми правами, потому что требуется предьявить атрибуты каждого пользователя в каждое правило. Но очень при этом очень эффективна в небольших приложениях, основанных на ролевой модели, так как позволяет делать правила на основе ролей.

Из интересного: здесь отображена модель ABAC - это механизм разграничения доступа на основе атрибутов. В ней обычно доступ определяется не на основе списка или таблицы доступа (как в ACL), а на основе правил и при подставлении конкретных атрибутов идентификатора в правило на выходе получаем информацию о том имеет ли пользователь право на доступ к ресурсу.

Вспомогательные процессы: - аудит - это логировние данных, позволяющих восстановить порядок действий, которые выполнил пользователь. Используется для расследования нештатных ситуаций - шифрование - основной способ сокрытия данных от доступа третьих лиц - лимитирование - лимиты, как правило основаны на ограничении доступа к ресурсам. Но бывает и лимиты времени. Это позволяет противостоять атакам "грубой силы", когда у атакующего есть огромные вычислительные ресурсы.

Два основных элемента: Аутентификация - проверка того кем является пользователь, т.е. по сути проверка личности Авторизация - проверка того, что пользователь может сделать

Краткая шпаргалка из книги "API Security in action" по организации безопасных API

Полный текст конспекта на эту тему - https://s0er.ru/codelabs/arch_stream_1/index.html?index=..%2F..index#4

Список проблем, который я делал для архитектурных стримов, по прежнему актуален: 1 полный игнор вопросов архитектуры (обычно вспоминают про архитектуру как про палочку-выручалочку когда уже «все плохо»); 2 неформализованные требования и ограничения; 3 отсутствие метрик качества и контроля; 4 приоритет наращивания функциональности (по сути увеличение прибыли, больше возможностей – больше продаж); 5 широкая вариативность повторного использования компонент, переусложненные компоненты с частичным использованием функциональности (одна и та же форма имеет несколько сценариев поведения, определяемых объектами-конфигураторами); 6 недостаток механизмов управления командой (нет разделения ответственности, «мы вам платим, вы нам делаете код»); 7 большое количество «ручного» труда, отсутствие сценариев автоматизации (СI/CD, DevOps); 8 несколько источников «правды» - кто-то пишет в почту, кто-то в мессенджер, кто-то что-то сказал на планерке, вопросы решаются на бегу; 9 отсутствие культуры и технологии разработки (команда преимущественно использует структурный подход к разработке, плохо понимает ООП, не понимает принципы изоляции и публичные интерфейсы, рефакторинг сводится к переименованию методов, а не к «прояснению» логики); 10 не фиксируется технический долг и он обычно уже большой; 11 разработчики плохо представляют что такое архитектура, не умеют мыслить в отрыве от когда, не понимают абстракций, имеют узкую квалификацию (слабое знание инженерных дисциплин); 12 Отсутствие тестирования, рефакторинга и прочих техник; 13 Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).